This post prices a single BigQuery query at four concrete scan sizes, under both on-demand and capacity-based pricing, with the arithmetic shown rather than just the rates. It covers compute only.

“How much does BigQuery cost” is usually answered with a rate card, which is not the same thing as answering what a query costs. A 1 GB dashboard refresh and a 10 TB pipeline job are different kinds of cost, and the pricing model that makes one cheap often makes the other expensive. Worse, only one of the two pricing models lets you calculate a query’s cost from the query itself. The other one genuinely doesn’t, and most cost estimates you’ll find online quietly get this wrong.

Storage is billed separately and has its own logical versus physical model choice, which isn’t covered here. For the full map of what BigQuery charges for, start with the pricing overview.

Learn more:
BigQuery Pricing Explained: What You're Actually Paying For

What does BigQuery charge for when you run a query?

Two different billing units, depending on which pricing model your project uses.

On-demand pricing charges for bytes scanned, at $6.25 per tebibyte (TiB) in US regions (check pricing for your region on cloud.google.com). Capacity-based pricing charges for slot-hours of compute capacity, at $0.06 per slot-hour on Enterprise edition in US regions (check pricing for your region on cloud.google.com). A slot is BigQuery’s unit of execution capacity.

Which gives two different BigQuery cost per query formulas, and one important difference in what you can know in advance:

Three details that change the arithmetic before we get to the examples:

Tebibytes, not terabytes. BigQuery’s on-demand pricing per TB is really per TiB, which is 1,024 GiB rather than 1,000 GB. Every calculation below divides by 1024.

The free tier is real but small. The first 1 TiB of query data processed each month is free, and it applies per billing account, not per project. That’s about 34 GB per day for your entire organization, across every pipeline, dashboard refresh, and analyst query. A single 1 TiB scan consumes the whole month’s allowance in one job. Any team with scheduled production workloads will exhaust it in the first day or two, so every number below assumes the free tier is already gone. If you’re running a small project that stays under it, your queries are free and none of this arithmetic applies to you yet.

There’s a floor per query. Charges round up to the nearest MB, with a minimum of 10 MB per query and 10 MB per table the query references. Querying a 2 KB lookup table still bills 10 MB, which matters when something runs thousands of times a day.

How much does it cost to process 1 TB in BigQuery?

On on-demand pricing, exactly $6.25 in US regions:

1 TiB × $6.25 = $6.25

That number is deterministic. You can get it before running anything, because the console’s query validator and a dry run both return the bytes the query will read. If that job runs nightly, it will cost about $187.50 a month, before storage.

Now, let’s move on to the same 1 TiB scan on capacity-based pricing. Say it’s a nightly aggregation, and INFORMATION_SCHEMA.JOBS reports that it consumed 8 slot-hours:

8 slot-hours × $0.06 = $0.48

About a thirteenth of the on-demand cost, which is exactly the result that convinces teams to move heavy pipelines onto a reservation. But that $0.48 is a weaker number than the $6.25, and it’s worth knowing why before you build a business case on it.

On capacity-based pricing, BigQuery doesn’t bill your query at all: it bills the reservation for capacity over time. Google’s autoscaling documentation is explicit about the consequences: you’re charged for the number of slots scaled, not the number of slots your jobs actually used. That charge applies even if the job that triggered the scale-up fails, and scale-up rounds up to 50-slot increments. Baseline slots bill whether your queries use them or not. Google’s own guidance is not to reconcile job-level slot data against your bill.

So $0.48 is an attribution at list price, not a line item. The honest version divides what the reservation really cost by the slot-hours it really served, which is almost always higher than list. That calculation has its own post:

Learn more:
What Does a BigQuery Job Actually Cost on a Reservation?

Why can’t you calculate capacity cost from bytes scanned?

Because slot consumption doesn’t track data volume. It tracks computational complexity.

BigQuery decides how many slots a query gets based on how parallelizable its stages are and how much capacity is free at that moment, and you can’t set it manually. What you’re billed on is slot-time, and two queries reading identical amounts of data can consume wildly different amounts of it.

Take 100 GiB, scanned twice by two different queries. On on-demand, both cost $0.61, because both read the same bytes:

• An incremental aggregation filtering a partitioned table and grouping by a few columns consumes 1.5 slot-hours, so about $0.09 attributed on capacity.
• An attribution model over the same 100 GiB, with self-joins and window functions across the full history, consumes 55 slot-hours, so about $3.30 attributed on capacity.

Same bytes. Same on-demand price. A 37x difference in slot-time, and the cheaper pricing model flips between the two. In the examples in this post, slot-time per byte ranges from under 2 GiB per slot-hour to nearly 150 GiB per slot-hour, so there is no conversion factor to apply and no rule of thumb that survives contact with a real workload.

This is the asymmetry that makes “what does my query cost” harder than it looks. On-demand cost is computable from the query. Capacity cost is only knowable by measuring the job.

What does a BigQuery query cost at 1 GB, 100 GB, 1 TB, and 10 TB?

Putting the sizes side by side, at US list prices with the free tier exhausted:

The on-demand column is arithmetic: bytes divided by 1024, multiplied by $6.25. The slot-hours column is not derived from the byte count and cannot be. The capacity column splits each example into two parts: the job’s own slot-time at the Enterprise list rate, plus an illustrative share of reservation waste on top. Your own slot-time comes from INFORMATION_SCHEMA. The waste does not. It comes from how the reservation was utilized when the job ran.

Learn more:
BigQuery Editions Comparison: Standard vs Enterprise vs Enterprise Plus

Two things worth reading off the table. At 1 GiB, both models cost rounding error, so pricing model choice is irrelevant for small queries and the 10 MB floor matters more than the rate. And the two 100 GiB rows are the whole point: identical data volume, opposite answer to the pricing model question.

Why does capacity-based pricing cost more than the slots the query used?

The first number in the capacity column is the job. The second is slots the reservation held that this job did not use.

Capacity-based billing charges for capacity that was scaled or kept available, not only for the slots a job burned. Scale-up rounds to 50-slot increments, and baseline slots bill whether a query is using them. That gap is slot waste. It cannot be read off the job in isolation. It depends on the whole reservation: how much baseline was idle, how far capacity scaled past what the job needed, and what else was running at the same time.

On a busy, well-sized reservation the overhead can be a few percent of the job. On a badly sized one, wasted slots can cost several times what the job itself consumed. The add-ons in the table sit in the common middle: large relative to a tiny query ($0.002 of waste on a $0.003 job) and a smaller share of a large one ($0.39 on a $4.20 job). They are not a rate you can apply to your own workload.

The number that already includes this waste is the reservation’s effective slot-hour cost, which comes from billing data rather than from the query. How that waste shows up, and the patterns that create it, are covered here:

Learn more:
BigQuery Slot Waste: Why Teams Overpay for Capacity They Never Use

Which BigQuery pricing model is cheaper for your queries?

It depends on your query mix, and there’s no threshold that settles it. Large scans doing simple work favour capacity. Small scans doing heavy computation favour on-demand. Almost every BigQuery estate runs both, all day, in the same projects.

The manual answer is to split them. Because reservations are assigned at project level, that means moving recurring high-scan pipelines into reservation-assigned projects and leaving ad hoc analysis and development on on-demand. That decision, and how to run the comparison against your own usage, is covered here:

Learn more:
BigQuery Pricing Models Explained: On-Demand vs Capacity-Based

New to BigQuery Editions and reservations? Get the practical foundations in our guide:

Once you’re on a reservation, the query-level arithmetic above stops being the whole story, because your bill is driven by how the reservation is sized and how it scales. Both have dedicated posts: baseline slots and commitments for sizing, and reservation autoscaling for what happens when demand exceeds your baseline.

Can individual jobs run on whichever model is cheaper?

You can set the pricing model query by query manually. Doing that by hand for every job is slow, and the choice has to be revisited as queries and reservation utilization change, so the effort does not scale. Most teams therefore stop at the project split, and that leaves money on the table. Projects contain both kinds of query, so any project-level assignment is a compromise: the join-heavy attribution model above stays on a reservation because it shares a project with pipelines that belong there, and it costs 5x what it would have on on-demand.

Deciding per job continuously is exactly what Rabbit’s Job Optimizer does: it evaluates each job against both pricing models and routes it to whichever is cheaper for that specific job, without splitting workloads into separate projects. Savings reach up to 60% on the individual jobs that get rerouted, which works out to roughly 15-20% across a full workload once you account for all the jobs that were already sitting on the cheaper model.

Underneath it, Rabbit computes per-job cost from your billing data and compares on-demand against capacity-based pricing for each one, using the effective slot-hour cost rather than list price. It connects over metadata-only APIs and reads INFORMATION_SCHEMA plus billing export, never query results.

If you want to see the method rather than read about it, our webinar on job-level reservation assignment works through per-query cost examples under both models and shows how to override project-level defaults job by job.

Learn more:
Unlock 15-20% Savings on BigQuery: The Power of Dynamic, Job-Level Pricing Optimization

Pricing model routing is one lever, and it interacts with the others. Reservation sizing, commitment coverage, storage billing model, and query patterns all pull on the same bill, which is why fixing one in isolation often just relocates the waste rather than removing it.

You’ve seen what a query costs at list price, and why the capacity side of that comparison needs measurement rather than multiplication. The BigQuery Savings Calculator does that estimate against your own workload, including what a mixed setup with job-level routing would be worth.