BigQuery slots explained

A BigQuery slot is a unit of compute that runs part of a query. How BigQuery decides how many slots a query gets, how slots are shared, what idle slots and autoscaling are, and how to see your own slot usage.

A slot is a virtual unit of compute, described on the pricing page as a virtual CPU. BigQuery splits every query into pieces of work and runs them on many slots at once. You don’t pick how many slots a query uses. BigQuery does, from the size of the data, the shape of the query and the slots that are free at that moment.

Slots matter for cost in one case. With capacity pricing you pay for slots over time. With on-demand pricing you pay for bytes read and slots aren’t billed separately, but your project is limited to about 2,000 at once.

How a query uses slots

BigQuery turns a query into a graph of stages. Each stage is a step such as scanning a table, filtering, joining or aggregating, and a stage can run on many slots in parallel. Data passes between stages through a shuffle. The graph isn’t fixed: BigQuery can change a plan while the query runs, and it can repartition a stage on the fly to spread the work more evenly.

BigQuery decides how many slots each stage could use, and that number has nothing to do with how many slots you own. If a stage could use 2,000 slots and only 1,000 are free, it takes the 1,000 and queues the rest of the work. As slots finish, they pick up queued work. The query takes longer, but it doesn’t fail and it doesn’t cost more. Google’s docs call this slot contention.

So slots set how fast a query finishes, not whether it can run. Google says BigQuery scales close to linearly with added slots, depending on the workload. The work a query did is reported as slot-milliseconds, in totalSlotMs on every job.

For a deeper look at stages and shuffle, see How a query runs.

On-demand slots

Under on-demand pricing a project can use up to 2,000 slots at once, and an organization up to 20,000. BigQuery sometimes goes above that for a short burst to speed up small queries. When a location is busy you may get fewer than 2,000.

Most on-demand projects never hit the ceiling. If yours does, you see queries that run slower at busy times. A reservation with a higher maximum is the way out. This is the case where capacity pricing helps a project that reads modest bytes but needs a lot of compute.

Fair scheduling

Inside a reservation, BigQuery shares slots in two steps. It splits the reservation evenly between the projects that have queries running, then splits each project’s share between that project’s queries.

This is by project, not by query. Take a reservation with 1,000 baseline slots and two projects. Project A runs one heavy query and project B runs 20 queries at once. Project A’s query gets 500 slots. Project B’s 20 queries share the other 500.

If A’s query only needs 100 slots, it takes 100 and project B’s queries share the remaining 900. Fair scheduling gives away what a project doesn’t use.

With 10 projects in a 1,000-slot reservation and all of them busy, each project gets 100 slots, no matter how many queries each one runs. The scheduler is fair over time. A job can briefly get more than its share, and BigQuery corrects that.

If one important job keeps getting too few slots, give it its own reservation. You can’t hand slots to a single job inside a shared reservation.

Idle slots

Slots are idle when they belong to a reservation’s baseline but no query is using them, or when they come from a commitment that no reservation has a baseline for. By default, a query in any reservation can borrow idle slots from other reservations in the same administration project.

Say reservation_a has 500 baseline slots and reservation_b has 100. If nothing runs in A, a query in B can use up to 600 slots. When a query starts in A, BigQuery takes its slots back within milliseconds, and B drops to its 100 baseline slots. You don’t pay extra for borrowed slots.

The limits:

• Idle slots are only shared between reservations of the same edition, in the same location and the same administration project.
• Autoscaled slots are not idle slots. They are added when needed and removed when not.
• A reservation with ignore_idle_slots = true can’t borrow, but it still lends its own idle slots to others.
• A reservation with no baseline and no autoscaling can still run queries on idle slots, but with no guarantee. Google advises against depending on idle slots for production jobs with deadlines. They can be taken back at any time.

Autoscaling

An autoscaling reservation has a maximum size and an optional baseline. BigQuery adds slots as demand rises, up to the maximum, and removes them when jobs finish. Three rules decide the bill:

• Slots are added in multiples of 50.
• You pay for the slots BigQuery scaled up to, not the slots your queries used.
• Billing is per second with a one-minute minimum. After a scale-up, the capacity is kept for at least 60 seconds. You can opt in to fluid scaling on a reservation to remove the minimum.

This example prices three bursts at the Enterprise pay-as-you-go rate of $0.06 per slot-hour (us-central1, prices as of October 2026):

WITH bursts AS (
  SELECT 'dashboard refresh' AS workload, 130 AS slots_needed, 12 AS seconds
  UNION ALL SELECT 'nightly load', 1020, 1800
  UNION ALL SELECT 'ad hoc query', 40, 75
)
SELECT
  workload,
  CAST(CEIL(slots_needed / 50) * 50 AS INT64) AS slots_billed,
  GREATEST(seconds, 60) AS seconds_billed,
  ROUND(CEIL(slots_needed / 50) * 50 * GREATEST(seconds, 60) / 3600 * NUMERIC '0.06', 4) AS usd
FROM bursts
ORDER BY workload

The dashboard refresh needed 130 slots for 12 seconds. It was billed as 150 slots for a minute, which is $0.15. The ad hoc query needed 40 slots for 75 seconds and was billed for 50. The 1,020 slots of the nightly load were rounded up to 1,050.

Because of this, don’t add up total_slot_ms from INFORMATION_SCHEMA.JOBS and expect it to match the invoice. Google’s docs send you to the reservation views in INFORMATION_SCHEMA for autoscaling charges, not to the jobs views.

Contention and queues

When there are more queries than slots, BigQuery works out how many queries can run at once and queues the rest. The queue holds up to 1,000 interactive and 20,000 batch queries per project per location. For a reservation you can set a maximum concurrency target. That is an upper bound that guarantees each running query a minimum number of slots. The default of 0 lets BigQuery decide.

Queued queries wait up to a queue timeout. The default_interactive_query_queue_timeout_ms and default_batch_query_queue_timeout_ms project options set it. If you set the timeout to -1, queuing is turned off, and a query that can’t start fails with an ADMISSION_DENIED error. Deleting a reservation makes its queued queries time out.

When a whole region is short of slots, BigQuery gives capacity out in this order: Enterprise Plus and Enterprise baselines and commitments first, then Enterprise Plus autoscaled slots, then Enterprise autoscaled slots, and last Standard and on-demand. Standard and on-demand queries are the ones that wait.

See your own slot usage

Every job records its slot-time. This query lists last day’s biggest queries by slot-time and the average number of slots each one held:

SELECT
  job_id,
  total_slot_ms,
  TIMESTAMP_DIFF(end_time, start_time, MILLISECOND) AS duration_ms,
  SAFE_DIVIDE(total_slot_ms, TIMESTAMP_DIFF(end_time, start_time, MILLISECOND)) AS avg_slots
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
ORDER BY total_slot_ms DESC
LIMIT 10;

Slot-time divided by wall-clock time is the average number of slots a job held. Change region-us to your location. For slot use over time rather than per job, JOBS_TIMELINE_BY_PROJECT has a period_slot_ms column for each second.

In Querylab.io, the Info tab of the results grid shows a job’s slot time and reservation (Results grid), and the execution plan shows slot-ms per stage and flags a query that waited for slots as “Slot Starvation Detected”. A project’s SQL Templates menu also has a “Slot Utilization Timeline” recipe over the reservation views (DDL operations). The BigQuery console also has a Monitoring page with slot charts, and a slot estimator that replays the past 30 days of usage to model what more or fewer slots would do to your workload.

What a slot is not

Slots are not machines you can see or configure. You can’t pin a query to particular slots or buy slots for one query. The number of slots in a reservation changes how fast the work finishes. It doesn’t change how many bytes a query reads.

To buy slots, see Reservations. To compare the two billing models, see On-demand vs capacity pricing.