BigQuery has two ways to charge you for running queries, and picking the wrong one can multiply your bill. The confusion usually comes down to one word — "slot." Here is the mental model.
A Slot Is a Unit of Compute
A slot is a virtual unit of CPU and memory that BigQuery uses to execute a query. A query is broken into stages, and BigQuery assigns slots to work through them in parallel. More slots means more parallelism means faster queries. That is all a slot is: a worker.
You don't manage slots individually — you either let BigQuery allocate them on demand, or you reserve a pool of them. That choice is the pricing model.
Model 1: On-Demand (Pay Per Byte)
By default, you pay for the bytes your queries scan, and BigQuery hands you slots automatically (up to a shared limit). You don't think about slots at all:
Cost = bytes scanned × per-TB rate
This is simple and great for spiky or low-volume workloads — you pay only for what you query, and an idle day costs nothing. It is also why partitioning and column selection matter so much here: fewer bytes, lower cost.
Model 2: Capacity (Pay Per Slot)
With editions/reservations, you buy a fixed number of slots for a period and run unlimited queries against them:
Cost = slots reserved × time (bytes scanned no longer billed)
Your bill becomes predictable and flat regardless of query volume. The catch: if your slots sit idle, you pay anyway.
Which One You Want
The rule of thumb:
- ▸On-demand — variable, unpredictable, or modest query volume. You want to pay for nothing when you query nothing.
- ▸Capacity — steady, heavy, predictable workloads where per-byte costs would exceed a flat reservation, or where you need cost predictability.
Many organizations use both: a reservation for the steady production load, on-demand for ad-hoc exploration.
Summary
A slot is just a unit of query compute. On-demand pricing bills the bytes you scan and allocates slots for you — ideal for spiky, lighter workloads. Capacity pricing rents a fixed slot pool at a flat rate — ideal for heavy, predictable use. Match the model to your query pattern and you stop overpaying for whichever one you drifted into by default.