BigQuery on-demand vs capacity pricing (editions)

On-demand BigQuery charges per TiB of data a query reads. Capacity pricing charges per slot-hour in Standard, Enterprise or Enterprise Plus edition. How to tell which one is cheaper for your workload.

BigQuery has two ways to pay for queries. On-demand charges for the bytes a query reads: $6.25 per TiB in the US multi-region, with the first 1 TiB each month free. Capacity pricing charges for compute instead: slot-hours, at a price set by the edition (Standard, Enterprise or Enterprise Plus). Every project starts on on-demand. You switch a project to capacity by assigning it to a reservation, and you can switch back at any time.

Neither model is cheaper in general. On-demand cost follows how much data your queries read. Capacity cost follows how long your queries keep slots busy. Those two numbers are almost unrelated.

The prices

Prices as of October 2026. Slot prices are the us-central1 rates printed on Google’s pricing page. They differ by location, so check yours. The on-demand rate is the US multi-region rate.

Commitments are not available in Standard. The pricing page also lists a separate “BigQuery CUD” column for pay-as-you-go slots, 10% off for one year and 20% off for three. You may need to opt in to be eligible. Storage is billed the same way under both models. See Storage pricing.

On-demand has a few rules of its own that capacity pricing doesn’t have: bytes are rounded up to a MB, and each table a query references has a 10 MB minimum. How a query is billed covers them.

What each model charges for

On-demand looks at the columns a query reads and ignores everything else. A query that reads 2 TiB costs $12.50 whether it takes 5 seconds or 5 minutes, and whether it is a plain scan or a 40-table join.

Capacity pricing looks at slots. A slot is a unit of BigQuery’s compute (see Slots). You pay for the slots allocated to your reservation, for as long as they are allocated, and the bytes a query reads don’t matter.

The same two queries can come out in opposite order under the two models. The slot-seconds here are invented to show the shape. You can read the real number for a finished query from total_slot_ms in INFORMATION_SCHEMA.JOBS.

WITH queries AS (
  SELECT 'wide scan, light compute' AS query, NUMERIC '2.0' AS tib_read, 3000 AS slot_seconds
  UNION ALL
  SELECT 'small table, heavy joins', NUMERIC '0.05', 400000
)
SELECT
  query,
  ROUND(tib_read * NUMERIC '6.25', 2) AS on_demand_usd,
  ROUND(slot_seconds / 3600 * NUMERIC '0.06', 2) AS enterprise_payg_usd
FROM queries
ORDER BY query DESC

The wide scan reads a lot of data and barely uses any compute, so on-demand is 250 times more expensive. The join-heavy query reads almost nothing and keeps slots busy for 111 slot-hours, so on-demand is the cheap one. A warehouse that mostly runs the first kind of query belongs on capacity pricing, and one that mostly runs the second kind belongs on on-demand.

Finding the break-even point

Always-on capacity has a fixed monthly price. Dividing it by $6.25 gives the number of TiB per month at which on-demand would cost the same. This is for 100 slots running all month (730 hours), pay as you go:

WITH editions AS (
  SELECT 'Standard' AS edition, NUMERIC '0.04' AS usd_per_slot_hour
  UNION ALL SELECT 'Enterprise', NUMERIC '0.06'
  UNION ALL SELECT 'Enterprise Plus', NUMERIC '0.10'
)
SELECT
  edition,
  100 * 730 * usd_per_slot_hour AS usd_per_month,
  ROUND(100 * 730 * usd_per_slot_hour / NUMERIC '6.25', 1) AS tib_on_demand_would_buy
FROM editions
ORDER BY usd_per_slot_hour

If your project reads fewer than about 700 TiB a month, then 100 always-on Enterprise slots cost more than on-demand would. This is a comparison against slots you keep running all month. Autoscaling slots, below, are only billed while they scale up, so they have a lower floor.

The INFORMATION_SCHEMA.JOBS view has what you need to compare the two for your own project. total_bytes_billed gives the on-demand cost of each job, and total_slot_ms gives the slot-time it used:

SELECT
  SUM(total_bytes_billed) / POW(1024, 4) * 6.25 AS on_demand_usd,
  SUM(total_slot_ms) / 1000 / 3600 * 0.06 AS enterprise_payg_usd
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND statement_type != 'SCRIPT';

This query is not run on this page. Treat the second column as a lower bound: autoscaling bills in steps of 50 slots with a one-minute minimum, so real capacity cost is higher than raw slot-time. The statement_type != 'SCRIPT' filter keeps a script’s parent job from being counted on top of its child jobs.

Querylab.io makes this comparison per query. It prices each query both ways from the dry run and shows a hint in the status bar when the other model would save a meaningful amount (pricing comparison). Query history has a Pot. Savings column with the same comparison for past jobs, and the Slots vs On-Demand Cost recipe under a project’s SQL Templates prices your workload on each edition and on-demand (DDL operations).

How capacity is billed

Capacity pricing has three moving parts.

• Autoscaling. You set a maximum size for a reservation, and BigQuery adds slots when queries need them. Slots are added in multiples of 50. You pay for the slots that were scaled up, not for the ones queries actually used.
• Minimum duration. Autoscaled slots are billed per second, with a one-minute minimum. You can opt in to fluid scaling on a reservation to drop the minimum.
• Baseline. A baseline is a number of slots that are always allocated to the reservation and always billed. Baseline slots can be covered by a commitment, which lowers the rate.

A reservation with a baseline of 0 and a maximum of 1,000 behaves like on-demand with a cap: you pay only while queries run, and a query can never use more than 1,000 slots. Google’s cost guide describes this setup as running editions “fully on demand”.

What on-demand limits

On-demand has no price per slot, but it does have a ceiling. A project gets up to 2,000 concurrent slots, and an organization up to 20,000. BigQuery may go above the limit for short bursts. Under heavy demand in a location you may get fewer than 2,000.

Two other things come with the choice.

• A query on on-demand that is too big for its slots doesn’t cost more. It runs longer.
• You can’t set a spending cap in dollars on on-demand. The only hard caps are daily bytes quotas and a maximum bytes billed on each query. See Controlling costs.

What the editions include

The edition decides which BigQuery features a reservation can use. Standard is cheapest and has the fewest. Features move between editions over time, and Google recommends not using editions as a way to block access to a feature.

On-demand is not the entry-level tier feature-wise. It has BigQuery ML, BI Engine, row and column security and customer-managed keys, which Standard doesn’t.

Mixing the two

The model is chosen per location and per project. You can run production in a reservation and leave experiments on on-demand, or the other way around. A project or folder with no assignment uses on-demand. A project assigned to the special reservation none stays on on-demand even when its folder or organization has a reservation.

The one trap is the default. If you assign only some projects to a reservation, every project you create later is on on-demand until someone assigns it. Assigning at the folder or organization level avoids this, because a project with no assignment of its own inherits the one above it. Standard edition allows only project assignments.

You can also keep on-demand alongside a commitment in the same location. On-demand jobs use separate capacity and don’t take slots from your commitment.

Choosing

Start on on-demand. It needs no setup, the first 1 TiB each month is free, and a dry run tells you what a query will cost before it runs. Look at capacity when one of these is true:

• Your on-demand bill is steady and large. The break-even above gives a rough threshold.
• You need a predictable monthly number more than the lowest number.
• You need Enterprise features, or want to isolate workloads from one another with separate reservations.
• Your queries are slow because of the 2,000-slot ceiling.

Slots explains what a slot is and how BigQuery shares them. Reservations covers commitments and assignments.