Snowflake credits, Databricks DBUs, BigQuery slots: the lines that break a warehouse comparison

A fourth meter arrived next to storage and compute

On 15 October 2026 Google made token-based cost controls generally available for BigQuery's generative AI functions, the AI.GENERATE, AI.IF, AI.CLASSIFY and AI.SCORE family that puts a model inside SQL. Four daily quotas are managed through the IAM quota system: 200 billion AI input tokens per project per day, 150 billion input tokens per user per day, 20 billion output tokens per project per day and 15 billion output tokens per user per day. The quotas are global, so a stray workload in an unwatched region still counts, and output quotas include the thinking tokens a reasoning model consumes.

That changes what a warehouse comparison has to cover. A mid-size enterprise used to compare bytes scanned, storage and slots; it now also has a meter that scales with model calls, and the four defaults above are the only published guardrail before someone asks for an increase.

Three units that never convert

Snowflake sells credits. On the first-generation standard warehouses the documentation lists 1 credit per hour for X-Small, 2 for Small, 4 for Medium, 8 for Large and 16 for X-Large, doubling at each step to 512 credits per hour at 6X-Large. Billing is per second with a 60-second minimum every time a warehouse starts, so a warehouse suspended between short queries pays for a minute of compute each time it wakes, and a team that resizes warehouses constantly is billed for the churn as well as the work.

Databricks sells DBUs and records them, per SKU and per resource, in the system.billing.usage table, which is the only place where a DBU becomes an attributable invoice line. That is also where the idle problem shows up: serverless notebooks have a default execution timeout of 2.5 hours, so a forgotten interactive session is bounded but not free, and the account's budgets and budget alerts are the control surface rather than a per-query price.

BigQuery sells two things. On demand it charges $6.25 per TiB scanned, with the first TiB each month free, a 10 MB minimum per table referenced and per query, and no charge for cached results or for queries that return an error. With editions it sells slot capacity instead, and the August 2026 release notes show why the edition matters: core graph processing now requires an Enterprise or Enterprise Plus reservation, with allowlisted users on Standard or on-demand billing supported only until 26 April 2027.

Retention and restart are where the comparison breaks

Storage looks comparable until the retention lines arrive. BigQuery publishes $0.000031507 per GiB-hour for active logical storage and $0.000021918 for long-term logical storage, with the first 10 GiB free each month, and it states that there are no charges for time travel and failsafe storage on logical storage. A team that keeps seven days of history for recovery is therefore not paying a second storage bill for it, which is not true of every warehouse in the shortlist.

The idle mechanics differ just as sharply. Snowflake's per-second model is generous on a warehouse that runs for hours and expensive on one that is started for a two-second query, because the 60-second floor applies to each start. BigQuery's slot model moves the risk to the reservation: capacity you have committed is paid for whether or not a query is running, and on-demand moves the risk back to the query, which is where the 10 MB minimum and the bytes-scanned rule do their damage on wide tables.

What a mid-size estate should put in the model

Take a warehouse that scans 20 TiB a day and stores 100 TiB. On BigQuery's on-demand rate the scan is 20 times $6.25 a day, about $125, or roughly $3,800 a month before the free tier, and the active logical storage for 102,400 GiB is about $2,355 a month at the published per-GiB-hour rate. Those are list prices with no committed-use discount, and they are the only two lines BigQuery guarantees.

On Snowflake the same estate is a function of how long warehouses run, not how much they scan, so the model has to be built from concurrency and queue time rather than data volume. The credit rate per hour is published; the price of a credit is set by cloud, region and edition and is not on the warehouse documentation page, which is exactly the gap a vendor call fills. Databricks is the same shape: the DBU consumption per workload is measurable from the billing log after a pilot, and not before.

The decision rule

If the workload is spiky, ad hoc and mostly SQL, BigQuery on demand is the cheapest way to start because the free tier and the per-TiB rate mean an idle month costs storage and nothing else, and the AI token quotas cap the newest risk. If the workload is a scheduled ELT estate with steady concurrency, Snowflake's credit ladder rewards a right-sized warehouse that runs for long stretches, and the 60-second minimum punishes only the habit of suspending between jobs.

If the estate is already Spark-shaped and the team wants notebooks, jobs and SQL on one billing log, Databricks wins on consolidation rather than unit price, because the DBU line is attributable per workload and the budget controls are built into the account. In all three cases, run the comparison on storage, retention, restart and the new token meter before comparing compute, because compute is the line each vendor quotes best.