How would you design BigQuery slot reservations and assignments for several teams sharing one organization?

## The objects you are designing with Three things, in a chain. **Capacity** is bought in one project — the admin project — either as pay-as-you-go autoscaling or as a one-year or three-year commitment, at a chosen edition. A **reservation** is a named pool of that capacity, with a baseline slot count and optionally an autoscaling maximum. An **assignment** binds a consumer — an organization, a folder, or a project — to a reservation for a specific job type (QUERY for queries, PIPELINE for load and export jobs, and a couple of others). Anything with no applicable assignment falls back to on-demand per-byte billing. That fallback is a design tool, not an accident. ## Split by workload class, not by org chart The instinct is one reservation per team, and it is usually wrong. Teams are a billing boundary; workloads are a contention boundary. What actually needs isolation is work with different latency contracts: - **Production pipelines** with an SLA — the nightly ELT that must finish before the business opens. Give it its own reservation with a baseline sized to its measured demand, so nothing an analyst does can push it past its window. - **BI and dashboards** — many small-to-medium concurrent queries during working hours. Size for daytime concurrency; a modest baseline with a generous autoscaling ceiling matches the shape well. - **Ad-hoc and exploration** — bursty, unpredictable, low duty cycle. Frequently the right answer is *no reservation*: leave those projects on on-demand, where idle costs nothing, and bound the risk with per-job byte ceilings and daily quotas instead. A small number of reservations is a feature. Every extra pool is capacity that can be idle while another pool queues. ## Commit only the floor Commitments discount capacity in exchange for locking spend for one or three years. Size the commitment to the demand you are confident persists — the level you would be embarrassed to be without — and cover everything above it with autoscaling, which costs more per slot but only while running. Committing to the observed peak is the classic and expensive mistake, and it is worse than overspending on-demand because idle committed slots appear on no query's bill; nobody sees the waste unless someone goes looking. ## Let the pools share Each reservation has an `ignore_idle_slots` property. Left at its default, jobs in one reservation may borrow slots that other reservations in the same admin project are not currently using, which is how you get isolation of the *guaranteed* floor without paying for isolation of the *peak*. Setting it to TRUE caps a reservation at its own slots and refuses borrowed capacity — appropriate only when you need strictly reproducible performance and are willing to pay for idle. In a multi-team design, sharing on by default plus a properly sized baseline for the SLA workload usually beats hard walls everywhere. ## Sizing from evidence Never size from intuition. Sum `total_slot_ms` per hour from `INFORMATION_SCHEMA.JOBS` and divide by the hour's wall-clock milliseconds to get average concurrent slots; do it per project so each candidate reservation has its own curve. Read the sustained level as the baseline and the peaks as the autoscaling maximum. Then, after cutover, watch `INFORMATION_SCHEMA.JOBS_TIMELINE`, which reports slot consumption in time slices, to see whether the shape you designed for is the shape you got, and watch job queueing to catch a baseline set too low. ## Attribution and chargeback Under on-demand, cost attribution is free: every job carries its own billed bytes. Under capacity, the invoice is for slots over time and does not decompose itself. You rebuild attribution one of two ways: a reservation per billing unit — clean but fragmenting — or shared reservations plus **labels** on jobs, apportioning cost by each team's share of `total_slot_ms`. Decide this before migrating; retrofitting labels onto pipelines after finance asks for a breakdown is unpleasant. ## Failure modes to design against **Baseline too small, autoscale ceiling too high** — everything technically works while the bill drifts upward invisibly. **Too many reservations** — several pools idle while one queues. **No fallback path** — a project accidentally unassigned suddenly bills per byte, which is not a fault but is a surprise if nobody expected it. **One pool for everything** — cheapest to run, until the quarterly backfill collides with Monday morning dashboards and there is no lever to pull. ## What a strong answer sounds like Measure, split by latency contract rather than by team, commit the floor and autoscale the peak, keep idle sharing on, leave spiky exploration on-demand, and build attribution deliberately. The tradeoff you are being asked to own is isolation versus utilization: every wall you build guarantees somebody's performance and wastes somebody's slots.