BigQuery reservations, commitments and assignments

How BigQuery capacity pricing is set up. A commitment buys slots for a term, a reservation is a pool of slots, and an assignment tells a project, folder or organization which reservation to use.

Capacity pricing in BigQuery is made of three separate objects. A commitment is a purchase of slots for a term (one or three years). A reservation is a named pool of slots that queries run on. An assignment connects a project, folder or organization to a reservation. A project with no assignment pays on-demand, so creating a reservation does nothing until you assign something to it.

All three live in one administration project, which receives the bill for the slots. Projects that use the slots pay only for their own storage.

How the objects fit together

You don’t need a commitment. A reservation with autoscaling and no commitment is billed at the pay-as-you-go rate per slot-hour. A commitment only lowers the rate for baseline slots. It does not cover autoscaled slots.

Commitments

A commitment is available in the Enterprise and Enterprise Plus editions, not in Standard. The pricing page shows these rates for Enterprise in us-central1 (prices as of October 2026):

Things that are easy to miss:

• You are billed monthly, but the commitment is for the full term. You can’t cancel it halfway.
• You can’t delete a commitment. To end one, set its renewal plan to NONE and it is removed when the term ends. The renewal plans are NONE, ANNUAL and THREE_YEAR, and you can change the plan until the commitment expires.
• You are charged from the moment the purchase succeeds.
• A purchase isn’t guaranteed. Commitments are subject to capacity in the region.
• Commitments are regional and edition-specific. A commitment bought in the EU multi-region can’t back a reservation in europe-west4, and an Enterprise commitment can’t back an Enterprise Plus reservation. Commitments can’t be moved to another region or administration project.
• Disabling the Reservations API does not stop commitment charges.

Committed slots only pay off if they are busy. A committed slot costs the same whether it runs queries or sits idle, while an autoscaled slot costs the pay-as-you-go rate only while it is scaled up. Dividing the committed rate by the pay-as-you-go rate gives the share of the time a slot has to be used before the commitment is cheaper:

WITH rates AS (
  SELECT 'pay as you go' AS plan, NUMERIC '0.06' AS usd_per_slot_hour
  UNION ALL SELECT '1 year commitment', NUMERIC '0.048'
  UNION ALL SELECT '3 year commitment', NUMERIC '0.036'
)
SELECT
  plan,
  100 * 730 * usd_per_slot_hour AS usd_per_month_for_100_slots,
  ROUND(usd_per_slot_hour / NUMERIC '0.06' * 100) AS break_even_utilization_pct
FROM rates
ORDER BY usd_per_slot_hour DESC

A one-year commitment beats autoscaling if the slots are busy more than 80% of the time, and a three-year commitment if they are busy more than 60%. Treat that as a rough guide, since autoscaling also rounds up to 50 slots and a minute. Commit to the steady load that is always there, and let autoscaling take the peaks.

Reservations

A reservation has these settings:

• Baseline slots (slot_capacity). Always allocated and always billed. Can be covered by a commitment. Standard edition has no baseline, only autoscaling.
• Autoscale maximum (autoscale_max_slots). The most slots autoscaling can add on top of the baseline.
• Idle slots. Whether the reservation may borrow unused slots from other reservations (ignore_idle_slots).
• Concurrency target (target_job_concurrency). A soft upper bound on how many jobs run at once.
• Edition. Standard, Enterprise or Enterprise Plus.

You can raise the baseline every few minutes. Lowering it can be limited to once an hour if you recently changed it and the baseline is above your committed slots.

Google recommends a non-zero baseline for predictable performance. A reservation with a baseline of 0 depends on autoscaling working, and if it doesn’t get slots, it falls back to idle slots, which have no guarantee.

Several reservations let you separate workloads. A common split is prod, elt and bi, so a heavy transformation job can’t take the slots a dashboard needs. Reservations in the same administration project can lend each other idle slots.

Assignments

An assignment gives a project, folder or organization a reservation to run on. A project uses the most specific assignment that applies: a project assignment beats a folder assignment, which beats an organization assignment. If none applies, the project is on-demand.

You can assign a project to the special reservation none to force on-demand. That is useful when an organization has a reservation and one project shouldn’t use it.

Each assignment has a job type:

Standard edition supports only QUERY and PIPELINE.

The PIPELINE type has a catch. Load and extract jobs are free by default because they use a shared pool of slots. Once you assign them to a reservation, they stop using the free pool and use your slots instead. If you assign PIPELINE jobs and your reservation is busy, loads slow down, and the slots are billed as part of your capacity.

You can also pick a reservation for a single query at run time, from the console, bq, SQL or the API, instead of using the project’s assignment. The reservation must be in the query’s location and you need the reservations.use permission. If a project’s default reservation is Enterprise Plus, it can only be overridden with another Enterprise Plus reservation. In Querylab.io the ⚙ popover in the status bar has a Reservation override. It lists the project’s reservations plus On-demand and writes SET @@reservation = '…' at the top of the query (pricing comparison).

Assign at the folder or organization

Assignments on single projects leave a gap. A project created next month has no assignment and quietly runs on-demand. Assign at the folder or organization level instead: a project with no assignment of its own inherits its folder’s or organization’s. Use none for the exceptions. Standard edition supports only project assignments.

Setting it up

These are the DDL statements for the three objects. They need an administration project and the right IAM roles, so none of them can run on this page. Each one passes a dry run (BigQuery checks the syntax) but was not executed.

-- Buy 100 slots for a year, in the Enterprise edition.
CREATE CAPACITY `admin_project.region-us.my-commitment`
OPTIONS (
  slot_count = 100,
  plan = 'ANNUAL',
  renewal_plan = 'NONE',
  edition = ENTERPRISE
);

-- A reservation with 100 baseline slots and room to grow by 400.
CREATE RESERVATION `admin_project.region-us.prod`
OPTIONS (
  edition = ENTERPRISE,
  slot_capacity = 100,
  autoscale_max_slots = 400
);

-- Send query jobs from one project to that reservation.
CREATE ASSIGNMENT `admin_project.region-us.prod.my-assignment`
OPTIONS (
  assignee = 'projects/my_project',
  job_type = 'QUERY'
);

The plan option takes ANNUAL, THREE_YEAR or TRIAL. Google’s reference examples for CREATE CAPACITY and CREATE RESERVATION leave out edition, which the option list does support. The managed disaster recovery guide writes the value unquoted (edition = ENTERPRISE_PLUS) and the reference calls it a string. BigQuery accepted both forms in a dry run.

To change a reservation later:

ALTER RESERVATION `admin_project.region-us.prod`
SET OPTIONS (
  slot_capacity = 300,
  autoscale_max_slots = 400
);

To see what exists, query the reservation views of INFORMATION_SCHEMA for your administration project and region: RESERVATIONS, CAPACITY_COMMITMENTS, ASSIGNMENTS and RESERVATIONS_TIMELINE. The change history is in RESERVATION_CHANGES and CAPACITY_COMMITMENT_CHANGES. The Slot Utilization Timeline recipe, under a project’s SQL Templates, compares allocated and used capacity from the reservation timeline (DDL operations).

SELECT * FROM `admin_project.region-us`.INFORMATION_SCHEMA.RESERVATIONS;

Limits and traps

• Regional. Slots and reservations in one location can’t be used in another. A query runs in the location of the tables it reads. If the table and the reservation are in different locations, the query uses on-demand pricing. The same happens for BigQuery Omni tables when the reservation is in the co-located Google Cloud region instead of the Omni region.
• Per organization. You can’t share capacity between organizations. Each organization can have up to 10 administration projects with active reservations in a location.
• Idle slots stop at the project. Idle slots are shared only inside one administration project, one location and one edition. Using several administration projects splits your pool.
• Standard is small. Standard reservations are capped at 1,600 slots, with up to 10 reservations per administration project and 16,000 slots per organization. Enterprise and Enterprise Plus allow 200 reservations and are limited by your quota.
• Slots can fail to allocate. Adding slots sometimes returns Failed to allocate slots for reservation in the current system state. Google says to retry with fewer slots, then wait 15 minutes and try again.
• Created but not assigned. A reservation that nothing is assigned to is never used, and the projects you meant for it keep running on-demand.

For how the slots in a reservation are shared between projects and queries, see Slots. To decide whether you need capacity at all, see On-demand vs capacity pricing.