BigQuery sells query compute two ways. On demand pricing charges per terabyte of data scanned, with no commitment, so the bill tracks exactly how much data each query reads. Capacity pricing buys compute as slots, measured in slot hours, as a baseline of reservations with optional autoscaling, so you pay for provisioned compute rather than bytes scanned. Neither is cheaper in the abstract. On demand wins when analytics are spiky, low, or unpredictable, because you pay nothing for idle capacity. Capacity wins when query volume is high and steady enough that reserved slots stay well utilised, because a fixed pool of slots serves unlimited queries at a predictable cost. The crossover is utilisation, not a spend threshold: capacity becomes cheaper the moment your steady demand keeps the slots busy, and stays expensive while they sit idle. The largest savings, though, often come before the model choice, by scanning less data in the first place.
Here is how each model prices, where the crossover is, and how to cut cost under either.
How does each model price?
| Dimension | On demand | Capacity (slots) |
|---|---|---|
| Billing unit | Terabytes scanned per query | Slot hours of provisioned compute |
| Commitment | None | Baseline reservations, optional commitments |
| Cost driver | Bytes read by every query | Slots provisioned and their utilisation |
| Predictability | Varies with query mix | Predictable once baseline is set |
| Best for | Spiky, low, or unpredictable analytics | High, steady, concurrent query volume |
Per terabyte and per slot rates vary by edition and region and change over time, so treat any number as indicative and verify against current BigQuery pricing before modelling a switch.
Where is the crossover?
Think in utilisation, not dollars. Under on demand you pay for bytes whether the platform is busy or idle, so a heavy steady workload pays repeatedly for scanning the same large tables. Under capacity you pay for a fixed pool of slots, so the more queries that pool serves, the lower the effective cost per query. The crossover arrives when your steady, concurrent demand would keep a reservation well utilised across the day. Below that, idle slots make capacity more expensive than paying per scan. The reliable way to find your own crossover is to measure: take a representative period of on demand spend, look at slot utilisation in the administrative views, and compare the cost of a baseline reservation sized to your steady concurrency against what on demand charged for the same work.
How do you cut cost under either model?
The cheapest query is the one that scans less, and that helps both models. Partition large tables by date so queries prune to the days they need, and cluster on common filter columns so scans skip irrelevant blocks. Select only the columns you use, never the whole row, because BigQuery bills the columns a query touches. Materialise expensive repeated aggregations instead of rescanning raw data each time. Under on demand these cuts reduce terabytes scanned directly; under capacity they reduce the slots a query consumes, so the same reservation serves more work. Either way, fixing wasteful queries usually returns more than the model choice, and it makes whichever model you land on cheaper.
A worked example
A Fortune 500 retailer ran BigQuery entirely on demand and watched the bill climb as dashboards multiplied. Two things were true at once: queries scanned far more data than they needed, and steady concurrency had quietly grown. We fixed the queries first, partitioning and clustering the largest tables and trimming select star dashboards, which cut terabytes scanned sharply on its own. Then, with the now steady, high concurrency profile measured against slot utilisation, a baseline capacity reservation sized to that demand came in well below the residual on demand cost, with autoscaling for peaks. The order mattered: reducing scans before choosing capacity meant the reservation was sized to lean demand rather than to waste. Figures are verified against billing data and anonymised.
Frequently asked questions
How does BigQuery on demand pricing work?
What is BigQuery capacity pricing?
When should you switch from on demand to capacity?
Find your own crossover
We measure BigQuery utilisation, cut wasteful scans, and model on demand against a right sized reservation so you land on the cheaper model with confidence, as an independent advisory that takes zero provider commissions and answers only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis. Download the GCP committed use discount kit, read the deeper GCP cost optimization guide, and tighten recurring jobs with scheduled queries and cost discipline.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.