When multiple queries compete for the same reservation, BigQuery uses fair scheduling to distribute slots equitably. The distribution algorithm has direct consequences for query performance and should inform project architecture decisions.
The Two-Level Algorithm
Fair scheduling works in two steps:
- Divide slots equally among projects running jobs in the reservation
- Divide each project’s share among its jobs
This is the critical insight: the first division is by project, not by query count.
Why This Matters: An Example
Consider a reservation with 1,000 slots:
- Project A runs 1 complex query
- Project B runs 20 simple queries
How are slots distributed?
| Project A | Project B | |
|---|---|---|
| Slots allocated | 500 | 500 |
| Queries | 1 | 20 |
| Slots per query | 500 | 25 |
Project A’s single query gets 500 slots. Project B’s 20 queries share 500 slots (25 each).
This is counterintuitive. You might expect the 21 queries to share 1,000 slots proportionally (roughly 48 each). Instead, BigQuery gives each project an equal share first, then distributes within each project. The single query in Project A gets 20x more slots than each query in Project B.
Project Architecture Implications
Project architecture matters for performance, not just for billing and security.
Fair scheduling divides by project first. If dbt and an analyst query are in the same project, all queries share the project’s allocation equally. If they’re in different projects, each project gets half the reservation, regardless of how many queries each runs.
This is why the multi-project pattern matters for more than just billing isolation. Separate projects assigned to different reservations means complete isolation. But even separate projects assigned to the same reservation get fair scheduling protection — each project gets an equal share.
The practical design rule: group workloads with similar priority into the same project, and separate workloads with different priorities into different projects (and ideally, different reservations). Production dbt in one project, BI dashboards in another, development in a third. Each gets its fair share.
The Ad-Hoc Analyst Problem
A common pattern in growing data teams:
- Team starts with one project for everything
- Production dbt runs fine with 8 threads
- Team grows, more analysts run ad-hoc queries
- dbt runs slow down during business hours
Fair scheduling divides the reservation equally among projects. With one project, all queries (dbt + analyst) share equally. As analyst query volume grows, dbt’s effective slot allocation shrinks. The fix is separating workloads into different projects with appropriate reservation assignments, not adding slots.
Fair Scheduling Within a Project
Within a single project’s allocation, BigQuery distributes slots equally among concurrent jobs. If Project A has 500 slots and runs 5 concurrent queries, each gets 100 slots.
This means your dbt threads setting directly affects per-model slot allocation. With 500 slots and threads: 8, each model gets roughly 62 slots. With threads: 4, each gets roughly 125 slots. More threads means more parallelism but less compute per model. For complex models that benefit from high parallelism (large scans, heavy aggregations), fewer threads with more slots per model can actually be faster.
The right threads setting depends on reservation size and model complexity. Monitoring slot usage per model helps identify the right value.
Regional Contention Priority
When an entire region is under capacity pressure (rare, but possible during major outages or extreme demand), BigQuery applies a different priority hierarchy that operates above fair scheduling:
- Enterprise Plus & Enterprise baseline/committed slots
- Enterprise Plus autoscaled slots
- Enterprise autoscaled slots
- Standard edition and on-demand
This priority only matters during regional capacity constraints. In normal operations, fair scheduling handles distribution within each reservation. But when the region itself is short on capacity, Enterprise Plus and Enterprise baseline slots get priority over Standard and on-demand.
Standard Edition and on-demand users are affected first during regional capacity pressure. Enterprise with baseline slots provides priority access during such events.