How to Reduce BigQuery Slot and Reservation Costs

To reduce BigQuery slot and reservation costs, decide on-demand versus editions on your real query volume, pick the cheapest edition that meets your feature needs, commit only the baseline slots you use every hour, autoscale above that baseline, and cut the bytes each query scans. Standard edition is about 0.04 US dollars per slot-hour, Enterprise about 0.06, and a one-year commitment cuts the Enterprise rate to roughly 0.048. The order matters: commit the floor, autoscale the peak, and shrink every query so it uses fewer slots.

Last updated: June 2026. Written by Morten Andersen and reviewed by Fredrik Filipsson, built on our See, Cut, Lock, Run method.

This article sits in our complete guide to Google Cloud cost optimization, the cluster pillar it links up to, and is part of the broader cloud cost optimization playbook. Tuning BigQuery capacity is both a Cut and a Lock step move. For the rest of the GCP data-processing stack, see our companion guide on optimizing Dataproc Serverless and Dataflow Prime costs.

What is a BigQuery slot?

A BigQuery slot is a unit of compute capacity, effectively a virtual CPU, that BigQuery uses to execute queries. Under capacity-based editions pricing you pay per slot-hour rather than per byte scanned, so your bill depends on how many slots your queries use and for how long, per the BigQuery slots documentation. The alternative, on-demand pricing, charges per terabyte of data scanned regardless of slots. The two models suit different usage patterns, which is the first decision this guide makes.

How much do BigQuery slots cost in 2026?

Under pay-as-you-go editions pricing, Standard edition is about 0.04 US dollars per slot-hour, Enterprise about 0.06, and Enterprise Plus about 0.10, per the BigQuery pricing documentation. Committing brings the rate down: a one-year Enterprise commitment is roughly 0.048 and a three-year commitment about 0.038 per slot-hour, which is below the Standard pay-as-you-go rate. On-demand querying, by contrast, is priced per terabyte scanned with the first terabyte each month free. The table summarizes the editions.

The figures above reflect Google Cloud pricing structure as we read it in June 2026. Confirm exact per-slot-hour and per-terabyte rates for your region in the linked Google Cloud documentation, because prices change.

How do you cut BigQuery slot and reservation costs?

Cut costs by matching the pricing model to your volume, committing only the baseline, autoscaling the peak, and shrinking every query. The steps below are the Cut-then-Lock sequence from our method.

1. Decide on-demand vs editions. Compare your monthly bytes scanned at the on-demand rate against a slot-based edition; high, steady query volume favors slots, occasional querying favors on-demand.
2. Pick the right edition. Choose Standard, Enterprise, or Enterprise Plus by feature need, not by default, since the per-slot-hour rate rises with each tier.
3. Set a committed baseline. Buy a one-year or three-year slot commitment for the baseline slots you use every hour, taking the lower committed rate on that floor.
4. Enable autoscaling above the baseline. Set a max-slot ceiling so peaks autoscale at the pay-as-you-go rate instead of forcing you to commit to peak capacity.
5. Cut the bytes scanned. Partition and cluster tables, select only the columns you need, and avoid SELECT star so every query consumes fewer slot-seconds or scans fewer bytes.

On-demand or slot-based: which should you use?

Use slot-based editions for high, steady query volume and on-demand for occasional or unpredictable querying. When your queries scan a large, consistent volume of data every day, a committed slot baseline costs less than paying per terabyte scanned over and over, and autoscaling absorbs the peaks. When querying is sporadic, on-demand avoids committing to slots that would sit idle, and the first terabyte free each month makes light use cheap. Many estates run a hybrid: editions with a committed baseline for the production analytics workload, and on-demand for ad hoc exploration. The full BigQuery cost playbook lives in our Google Cloud guide.

What inflates a BigQuery bill?

The biggest BigQuery cost mistakes are committing to peak slots, over-buying the edition, and scanning more data than each query needs. Committing for the daily peak leaves slots idle overnight; autoscaling fixes that. Defaulting to Enterprise Plus when Enterprise or Standard covers the feature set pays a higher per-slot rate for nothing. And the classic on-demand trap is SELECT star against unpartitioned tables, which scans the whole table on every run. Partitioning, clustering, selecting only needed columns, and using the query result cache all cut bytes scanned, which lowers cost on both pricing models. Working the five steps above removes each of these in turn.

Frequently asked questions

What is a BigQuery slot?

A BigQuery slot is a unit of compute capacity, a virtual CPU, that BigQuery uses to run queries. Under capacity-based pricing you pay per slot-hour rather than per byte scanned, so the bill depends on how many slots your queries use and for how long, not on the data volume.

How much do BigQuery slots cost in 2026?

Under pay-as-you-go editions pricing, Standard edition is about 0.04 US dollars per slot-hour, Enterprise about 0.06, and Enterprise Plus about 0.10. One-year and three-year commitments cut the Enterprise rate to roughly 0.048 and 0.038 per slot-hour. Confirm current rates in the BigQuery pricing documentation.

Should I use on-demand or slot-based BigQuery pricing?

Use slot-based editions pricing for high, steady query volume where a committed slot baseline costs less than scanning the same data on demand. Use on-demand pricing for occasional or unpredictable querying, where paying per terabyte scanned avoids committing to slots you would not keep busy.

How does BigQuery slot autoscaling save money?

Slot autoscaling lets you commit to a small baseline of slots and add capacity automatically up to a ceiling only when queries need it, billed at the pay-as-you-go rate for that edition. You avoid committing to peak capacity, paying the lower committed rate on the steady floor and the on-demand rate only on the spikes.

The short version

Reduce BigQuery costs by matching on-demand or editions to your volume, picking the cheapest edition that fits, committing the baseline slots, autoscaling the peak, and shrinking the bytes each query scans. Commit the floor, not the peak. When you want your query history modeled and your reservations sized, that is what our Google Cloud cost optimization service delivers.