BigQuery Slot

A slot is the unit of compute BigQuery uses to run a query. Google’s Understand slots page defines it as “a virtual compute unit used by BigQuery to execute SQL queries, Python code, or other job types,” and the Query plan and timeline page describes it as “an abstracted representation of multiple facets of query execution, including compute, memory, and I/O resources.”

Both halves of that definition matter. A slot is not a CPU core, so you cannot reason about it as though you were sizing a machine. And because it bundles memory and I/O alongside computation, a query can be constrained by any of the three while the slot count stays the same.

How you obtain slots is the larger decision. Under on-demand pricing, you are billed by bytes processed rather than managing a reservation. The project has a soft capacity limit of 2,000 concurrent slots, with transient burst capability. Under capacity pricing, slots are allocated in reservations; Google lists 50 slots per reservation as the minimum capacity.

A reservation can combine baseline and autoscaling capacity. Baseline slots remain allocated and charged even when no query runs. Autoscaling adds capacity under load after the configured baseline and any applicable idle capacity are consumed, then reduces it when no longer needed. A commitment covers capacity for a fixed term and cannot be reduced during that term; it is different from changing a reservation’s baseline.

Reservations can share idle slots within the same administration project and location when their configuration permits it. The owning reservation reclaims that capacity when it needs it, so shared idle capacity can reduce waste but is not a dependable substitute for a workload’s own baseline. Idle slots are not shared across editions.

Slots are also how you measure what a query cost in compute terms. The query plan reports totalSlotMs, and Google ties it directly to cost accounting. Read alongside bytes processed, it points to where to look. A query that scans enormous amounts of data may need better partition pruning, narrower projections, or a different table layout. A query with modest input and high slot time is doing expensive work — joins, aggregations, window functions — and may need to be rewritten. The two metrics are clues rather than a diagnosis: check the scan, shuffle, and join stages in the query plan and the pruning conditions before choosing between a layout change and a rewrite.

Do not confuse this with a replication slot in PostgreSQL, which is a bookkeeping position in a write-ahead log and has nothing to do with compute. The closer comparison is a virtual warehouse, which is also a unit of purchased compute — but a warehouse is something you size and start, whereas slots are allocated to a query by the service.

Further reading

• Google, Understand slots
• Introduction to workload management
• Query plan and timeline

See the worked examples in BigQuery Architecture and Cost.