A slot is BigQuery's unit of compute: a virtual share of CPU and memory that executes part of a query. A query is split into stages, each stage into many small tasks, and tasks run on slots. More slots available means more tasks run in parallel, so the query finishes sooner.
Where slots come from
- On-demand pricing: your project draws from a shared pool, with a default cap of around 2,000 slots per project, and BigQuery can burst beyond that when spare capacity exists. You do not choose or reserve anything, and you pay per bytes scanned.
- Capacity pricing (editions): you buy slots, with a baseline (always on) and an autoscaling maximum. Slots are billed per slot-hour. You can group them into reservations and assign projects to them, so that, for example, ETL and BI use separate pools.
What happens under contention
If a query needs more slots than are free, its stages wait. A query that took 20 seconds with plenty of slots can take minutes when the pool is shared with a large job. In a reservation with a fixed size, queries from all assigned projects compete for the same slots, and BigQuery shares them fairly across them. You see this as longer stage wait times.
How to see it
In the job details, look at slot-milliseconds consumed, and the execution graph for stages with long wait time. In INFORMATION_SCHEMA.JOBS (and JOBS_TIMELINE) you can see total_slot_ms per job and slot usage over time. Dividing total_slot_ms by the job's elapsed milliseconds gives an average slot count.
SELECT job_id, total_slot_ms / TIMESTAMP_DIFF(end_time, start_time, MILLISECOND) AS avg_slots FROM `region-us`.INFORMATION_SCHEMA.JOBS WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY) ORDER BY avg_slots DESC LIMIT 20;
What to say
More slots means more parallelism, not a smarter query. If a query is slow because it reads too much data or has a skewed join, adding slots helps only partly. Reduce the data and fix the plan first, then think about capacity.