Gnok is in Limited Availability: a preview with no uptime commitment. Don’t store sensitive data; data may be deleted.
Skip to main content

Billing & Credits

Limited Availability

Prices aren't published yet, and online payment is off. Every new workspace starts with a 60-day trial with $400 of credits; paid plans are pay-as-you-go and are set up through support@gnok.com. Rates, credits and dollar amounts in the SQL examples on this page are illustrative, not prices or an offer.

Your trial​

A new workspace starts a 60-day trial with $400 of credits on the day Gnok approves it. No payment card is needed, and there is no permanent free plan.

What the credits cover. Gnok meters four things and draws each from your credits at Standard list prices:

MeterWhat counts
Warehouse computeThe time each of your warehouses is running, by the second, at the rate of its size. A suspended warehouse costs nothing.
NotebooksThe time each notebook kernel is running.
StorageThe bytes your tables' current snapshots, @stage files, and model and index artifacts occupy, sampled daily and averaged over the month.
AILanguage-model tokens (input and output priced separately) and embedding tokens, per model.

Your warehouse. At approval Gnok creates compute_wh, an X-Small warehouse that suspends after 5 minutes without queries and resumes on the next one, so idle time isn't metered. Statements run on it unless you USE WAREHOUSE another. You can create up to 3 warehouses of at most Medium size.

Watching the credits. In Studio, Usage & billing shows the credits used and remaining, the days left, and usage by meter. Workspace administrators get an email at 50%, 80% and 100% of the credits, and 7 days and 1 day before the trial ends. SHOW WAREHOUSE USAGE and SHOW METERING HISTORY (below) show the compute side in SQL.

When the trial ends. When the credits are used up or the 60 days pass, whichever is first, compute stops: your warehouses are suspended, and new queries, notebooks and AI requests are refused with a message that says why, for example Your trial has used its $400 of credits. Contact support@gnok.com to keep going. Signing in still works, and your data is kept for 30 days after the trial's end date. During those 30 days you can still export your data at no charge from Usage & billing: read-only queries, table downloads and Export all tables on your default warehouse, up to 2 CU of compute a day (see Exporting your data). If the workspace isn't upgraded within those 30 days, it is deleted as described in Deleting your workspace.

Upgrading. Upgrading restores access immediately, and credits you haven't used keep applying to your usage until the trial's end date. Paid plans are pay-as-you-go: you pay for what you use, with compute per second, storage per TB-month and AI per million tokens. Standard is self-serve and Enterprise is by contract. Online payment isn't available yet, so to upgrade, email support@gnok.com from a workspace administrator's address; prices are shown before you can be charged. After a Standard subscription ends, compute stops the same way, data is kept for 30 days with the same free export, and subscribing again restores it.

The trial's length, credits and limits may change for workspaces that start later. Limited Availability lists the current values, and section 4 of the Terms of Service has the exact terms.

Compute Units​

Compute Units (CUs) express metered compute consumption. A warehouse consumes CUs at the rate of its size for every second it runs, whether or not queries are executing; auto-suspend stops the meter. SHOW WAREHOUSE USAGE reports the billing mode: STANDARD means warehouse running time is metered (your own warehouses), and the per-query attribution records it also shows describe execution work and are informational.

Warehouse sizes​

A warehouse size is a number of workers, and each worker is a pod with the CPU and memory below. CUs per hour equal the number of workers. These are the engine's current settings (gnok-warehouse-controller, size.rs) and may change before general availability.

SizeWorkersvCPU per worker (up to)Memory per workerCU per hour
X-Small (xsmall)112 GiB1
Small (small)224 GiB2
Medium (medium)448 GiB4
Large (large)8816 GiB8
X-Large (xlarge)161632 GiB16
2X-Large (x2large)321632 GiB32
3X-Large (x3large)641632 GiB64
4X-Large (x4large)1281632 GiB128

A worker is guaranteed half of its vCPU and can use the full amount when its node has spare capacity; memory per worker is a hard limit. Sizes above X-Large add more workers of the X-Large worker shape rather than bigger workers. During the trial you can create warehouses up to Medium; larger sizes come with a paid plan.

A larger warehouse finishes a query sooner when the query can use more workers, but consumes CUs faster. Compare actual usage on representative workloads; estimates don't guarantee a final charge.

EXPLAIN COST​

Before running an expensive query, use EXPLAIN COST to see estimated CU consumption across warehouse sizes:

EXPLAIN COST SELECT COUNT(*) FROM sales;

An illustrative response contains estimates by warehouse size, a scan summary, and the original query. The est_cost_usd column uses the engine's built-in reference rate, not a published price:

warehouse_size | est_time_secs | est_cus | est_cost_usd | is_current | recommendation
Small          | 0.1           | 0.0001  | 0.000111     | False      |
Medium         | 0.1           | 0.0001  | 0.000222     | True       |
Large          | 0.1           | 0.0002  | 0.000444     | False      |
X-Large        | 0.1           | 0.0004  | 0.000889     | False      |
---            | 0.0           | 0.0     | 0.0          | False      | Scan: 0.0 MB (1 files) | Rows: 8
Query          | 0.0           | 0.0     | 0.0          | False      | SELECT COUNT(*) FROM sales

is_current=True marks your current warehouse size. The recommendation row shows scan details (files, rows, shuffle bytes) and sizing advice.

This helps right-size the warehouse: smaller warehouses are cheaper per CU but slower; larger warehouses finish faster but cost more due to parallelism overhead. The sweet spot is typically where estimated CUs are lowest.

Resource Monitors​

Resource monitors set credit spending limits on warehouses and enforce them automatically. Each time usage is recorded (per-query compute-unit attribution or periodic warehouse metering), Gnok adds the credits to the monitor's total and checks its thresholds, without adding work to your queries.

Create a Resource Monitor​

CREATE RESOURCE MONITOR monthly_budget
  WITH CREDIT_QUOTA = 1000
  FREQUENCY = MONTHLY
  TRIGGERS
    ON 50 PERCENT DO NOTIFY
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

Response:

Resource monitor 'monthly_budget' created (quota=1000 credits, frequency=MONTHLY,
  triggers=[50% -> NOTIFY, 80% -> NOTIFY, 100% -> SUSPEND])

Trigger Actions​

ActionBehavior
NOTIFYRecords an alert in resource_monitor_alerts
SUSPENDRecords an alert, then sets the warehouse status to suspended — new queries are rejected

Each trigger fires once per billing period. When the period resets (daily/weekly/monthly), all triggers re-arm automatically.

Assign a Resource Monitor to a Warehouse​

ALTER WAREHOUSE analytics_wh SET RESOURCE_MONITOR = monthly_budget;

Response:

Warehouse 'analytics_wh' resource monitor set to 'monthly_budget'

This links the warehouse to the monitor. As queries run and billing records accumulate, the monitor's credits_used increments automatically. Dropping the monitor automatically unlinks it from the warehouse.

View Resource Monitors​

SHOW RESOURCE MONITORS;

Response:

monitor_name   | credit_quota | frequency | credits_used | triggers
monthly_budget | 1000         | MONTHLY   | 42.5         | 50% -> NOTIFY, 80% -> NOTIFY, 100% -> SUSPEND

credits_used reflects real-time accumulated CUs since the last period reset.

Drop a Resource Monitor​

DROP RESOURCE MONITOR monthly_budget;
DROP RESOURCE MONITOR IF EXISTS monthly_budget;

Metering and Usage Queries​

Warehouse Usage​

View CU consumption and the effective billing mode for the current period:

SHOW WAREHOUSE USAGE;

Response:

metric                      | cus | cost_usd | detail
Billing Mode                | 0.0 | 0.0      | STANDARD (CuMeter — warehouse running time)
Warehouse Compute (billing) | 0.0 | 0.0      | 44.000000 CUs
  Query Execution           | 0.0 | 0.0      | 0.016470 CUs (153 queries)
  Idle Time                 | 0.0 | 0.0      | 43.983530 CUs (warehouse running, no queries)
---                         | 0.0 | 0.0      |
Queries Executed            | 0.0 | 0.0      | 153
Bytes Scanned               | 0.0 | 0.0      | 334859
Period                      | 0.0 | 0.0      | 2026-04-01 to 2026-04-04 UTC

This illustrative response shows the billing mode, query versus idle consumption, and the period. The output also has a Total Cost row and a cost_usd column computed at the engine's built-in reference rate; they are not prices or an account quote. What your trial's credits actually covered is in Studio under Usage & billing.

Metering History​

View aggregated metering records:

SHOW METERING HISTORY;

Returns per-warehouse usage records with columns: warehouse_name, warehouse_size, record_type, cus_consumed, bytes_scanned, queries_executed, period_start.

Storage​

Storage is metered as the bytes your tables' current snapshots, @stage files, and model and index artifacts occupy, sampled once a day and averaged over the month, and is drawn from your trial's credits. During the trial, storage is also limited to 10 GiB per workspace. Review table maintenance and your retention requirements before removing data.

Cost Optimization Tips​

Right-size your warehouses​

Use EXPLAIN COST to find the warehouse size with the lowest estimated CU consumption. Larger is not always cheaper -- parallelism overhead can increase total CU cost even as wall-clock time drops.

Keep auto-suspend short​

Warehouses should suspend after a short idle period to avoid being metered for unused capacity. compute_wh suspends after 300 seconds; set your own warehouses the same way:

ALTER WAREHOUSE analytics_wh SET
  AUTO_SUSPEND = 300,     -- seconds of idle before suspend
  AUTO_RESUME = TRUE;     -- resume automatically on next query

Use EXPLAIN COST before large queries​

For ad-hoc analytical queries, preview costs before execution. This is especially important for queries that scan large tables without selective filters.

Set resource monitors on all warehouses​

Even development warehouses should have resource monitors to prevent unexpected costs from runaway queries or forgotten sessions.

Schedule heavy workloads during off-peak hours​

Schedule work to avoid unnecessary concurrency and repeated execution. There are no time-of-day discounts.

Monitor usage regularly​

Review SHOW METERING HISTORY weekly. Look for warehouses with high CU consumption but low query counts (indicates oversized warehouses or long-running queries that could be optimized).

Further Reading​

Last updated on