BigQuery Reservation Hierarchy

BigQuery’s capacity model has three layers: commitments, reservations, and assignments. Each layer answers a different question: how much capacity is purchased, how it is organized, and which projects use it.

Commitments: Buying Capacity

A commitment is a purchase of compute capacity for a minimum duration. You’re essentially saying, “I’ll pay for X slots for at least Y time.”

Commitments are optional when using BigQuery Editions. Without a commitment, you pay the standard pay-as-you-go rate for your edition. Commitments provide significant discounts:

• 1-year commitment: 20% discount
• 3-year commitment: 40% discount

Commitments are cost-effective for predictable, steady workloads where slot usage is consistent month over month. Bursty or unpredictable workloads are better served by pay-as-you-go.

Key constraints:

• Commitments are regional — slots in us can’t run jobs in eu. This ties directly to your regional architecture decisions.
• Commitments cannot be moved between projects after creation.
• Only available for Enterprise and Enterprise Plus editions. Standard edition doesn’t support commitments.

Reservations: Creating Slot Pools

A reservation is a pool of slots carved out for specific workloads. Think of it as a “bucket” that holds a portion of your committed capacity.

Multiple reservations provide isolation. Example configuration:

• A prod reservation with 500 slots for production pipelines
• A bi reservation with 300 slots for dashboard queries
• A dev reservation with 100 slots for development work

Each reservation operates independently. Jobs in dev cannot use slots from prod, ensuring production pipelines always have their allocated capacity.

Each reservation has its own baseline and autoscaling configuration. You can guarantee 500 baseline slots for production while letting dev autoscale from 0 to 200. The reservation is where you express your priorities in concrete terms.

Reservations also participate in idle slot sharing (Enterprise and Enterprise Plus only). When prod isn’t using all its slots, dev can borrow the idle capacity. When prod needs them back, it reclaims them instantly.

Assignments: Connecting Projects to Reservations

An assignment links a Google Cloud project (or folder, or organization) to a reservation. Once assigned, all BigQuery jobs in that project use slots from that reservation instead of on-demand pricing.

The hierarchy matters for resolution:

• Project assignment overrides folder assignment
• Folder assignment overrides organization assignment
• No assignment causes the project to use on-demand pricing

You can also assign by job type. BigQuery supports several assignment types:

This means you could assign a project’s QUERY jobs to one reservation while its PIPELINE jobs use another. In practice, most teams assign all job types to the same reservation, but the granularity exists for workloads that need it.

The assignment layer is what makes the multi-project pattern work for slot management. By assigning different GCP projects to different reservations, you get workload isolation without any application-level changes. Your dbt production project uses the prod reservation’s slots; your Looker project uses the bi reservation’s slots. The projects don’t know or care about reservations — the assignment handles the routing.

The Administration Project

Best practice: create a dedicated administration project that holds all your commitments and reservations. This project doesn’t run queries or store data; it just manages capacity.

Name it something obvious like bq-yourcompany-admin. This approach:

• Centralizes billing for compute resources. All slot costs appear on one bill.
• Simplifies capacity management. One place to view and adjust all reservations.
• Keeps your data projects clean. No reservation configuration mixed in with data and queries.

One critical rule: idle slots can only be shared across reservations in the same admin project. If you use multiple admin projects, their slots remain completely isolated. This is the most common architectural mistake with reservations — splitting capacity across admin projects unintentionally, then wondering why idle slot sharing isn’t working.

flowchart LR
      C[/"1000 slots (1-year)"/]

      C -->|"assigned to"| R1["Reservation: prod<br/>500 slots"]
      C -->|"assigned to"| R2["Reservation: analytics<br/>300 slots"]
      C -->|"assigned to"| R3["Reservation: dev<br/>200 slots"]

      R1 -->|"used by"| P1([Project: dbt-prod])
      R2 -->|"used by"| P2([Project: looker-prod])
      R3 -->|"used by"| P3([Project: analytics-dev])

Summary

The three layers stack as follows:

1. Commitments determine total capacity and cost.
2. Reservations carve that capacity into isolated pools with specific baseline and autoscaling configurations.
3. Assignments route projects to the appropriate reservation.

Concerns are separated cleanly: projects can be reassigned without modifying reservations; reservations can be resized without changing assignments; commitments can be added independently.

For teams running dbt on BigQuery, this hierarchy is what enables the “separate projects by workload” pattern described in dbt Slot Management on BigQuery. Your production dbt runs get guaranteed capacity through a dedicated reservation, while development work uses a smaller pool or stays on on-demand pricing entirely.