BigQuery project caps are GA: limit slots and concurrency per project

3 hours ago

7 min read

BigQuery project caps are GA: limit slots and concurrency per project, title on a teal data skyline. Data Studios original cover

Google made BigQuery project caps generally available on November 11, 2026, according to the BigQuery release notes. Project caps, also called scheduling policies, let a reservation administrator set a maximum number of slots and a maximum number of concurrent queries for each project that runs on a shared reservation. The release notes state that the feature is supported only in the Enterprise and Enterprise Plus editions.

The same release-notes date brought a second workload-management change to general availability: an optional principal property on reservation assignments. With it, an administrator can route queries to a specific reservation based on the identity that runs the job, such as a named user, a service account or a third-party identity, instead of relying only on the project, folder or organization the job comes from.

Both features address a recurring problem in companies that share one reservation between dashboards, scheduled pipelines and ad hoc analysis. One busy project can take a large share of the slots that a dashboard workload depends on, and until now the main controls were separate reservations or the default fair scheduler. Google has not announced a separate charge for either feature; both are settings on reservations and assignments that customers already pay for through BigQuery editions.

··········

HOW BIGQUERY FAIR SCHEDULING SHARES SLOTS TODAY.

BigQuery documentation describes the default behavior inside a reservation as fair scheduling. The scheduler enforces equal sharing of slots among the projects that have running queries in the reservation, and within each project the same equal sharing applies across that project's jobs. Google calls the result eventual fairness, because individual jobs can receive a disproportionate share for short periods before the scheduler corrects it.

The documentation gives a reservation of 1,000 baseline slots with no autoscaling as its example. If project A runs one demanding query and project B runs 20 concurrent queries, each project receives 500 slots, and project B's 500 are divided among its 20 queries. If ten projects all have enough demand, each receives 100 slots regardless of how many queries it runs. The share is decided per project, so a project with many light queries and a project with one heavy query end up with the same allocation when both are busy.

Fair scheduling protects against a single project taking the whole reservation, but it gives every busy project the same weight. An exploratory project used by analysts gets as much capacity as the project that refreshes executive dashboards every morning, and nothing in the default behavior limits how many queries a project admits at once.

··········

BIGQUERY PROJECT CAPS: MAXIMUM SLOTS AND MAXIMUM CONCURRENCY.

Google's documentation describes project caps as a way to customize the default fair scheduling behavior by setting usage and concurrency limits for projects that use a reservation. The caps apply even when a project would be eligible for more capacity under fair scheduling. There are two settings.

........

Setting	What it limits	Documented behavior
Maximum slots	Slot consumption of the project's queries in the reservation	Minimum value 100; approximate cap, not a strict limit
Maximum concurrency	Queries admitted at the same time for the project	Applied at admission; running queries are not canceled
Reservation default	Both caps for every assigned project	Set on the reservation
Project override	Both caps for one project	Set with a project cap assignment

........

Changes take up to one minute to apply, and a change to a per-project maximum slots override takes effect only when a new query starts. When the concurrency cap is lowered below the number of queries already running, those queries continue and new queries wait until enough of them finish. The documentation also states that project-level slot caps are not enforced on the training phase of ML_EXTERNAL jobs, and that a project cap assignment must have its job type unset or set to JOB_TYPE_UNSPECIFIED.

Defaults are set on the reservation itself. The SQL example in the "Manage workload reservations" documentation adds two options to CREATE RESERVATION.

CREATE RESERVATION
  `ADMIN_PROJECT_ID.region-LOCATION.RESERVATION_NAME`
OPTIONS (
  slot_capacity = NUMBER_OF_BASELINE_SLOTS,
  edition = EDITION,
  autoscale_max_slots = NUMBER_OF_AUTOSCALING_SLOTS,
  scheduling_policy_max_slots = MAX_SLOTS_PER_PROJECT,
  scheduling_policy_concurrency = MAX_CONCURRENCY_PER_PROJECT);

In the Google Cloud console the same defaults sit under Advanced settings when creating a reservation, as Project Concurrency and Project Max Slots. A per-project override is a separate assignment whose assignee must be a project; folders and organizations are not supported for project caps.

CREATE ASSIGNMENT
  `ADMIN_PROJECT_ID.region-LOCATION.RESERVATION_NAME.ASSIGNMENT_ID`
OPTIONS (
  assignee = 'projects/PROJECT_ID',
  scheduling_policy_max_slots = MAX_SLOTS,
  scheduling_policy_concurrency = MAX_CONCURRENCY);

The bq command-line tool accepts the same values through the --scheduling_policy_max_slots and --scheduling_policy_concurrency flags of bq mk with --reservation_assignment. An existing override is changed with ALTER ASSIGNMENT; setting a value to null removes that setting, and deleting the assignment removes all of them. Active overrides appear in the scheduling_policy and assignment_type columns of INFORMATION_SCHEMA.ASSIGNMENTS. In the console the path is Administration, Workload management, Assignment rules, with the rule type set to Project cap.

··········

[[ADPLUS_300x250_1]]

WORKED EXAMPLE: CAPPING AN AD HOC PROJECT ON A SHARED RESERVATION.

The following scenario is illustrative and every figure was computed in Python. A company runs one Enterprise edition reservation with 200 baseline slots and 400 autoscaling slots, for a maximum of 600 slots. Three projects are assigned to it: one for BI dashboards, one for ELT pipelines and one for ad hoc analyst queries. The cost line uses the Enterprise pay-as-you-go rate of $0.06 per slot-hour shown on Google's BigQuery pricing page on November 12, 2026, and assumes the ad hoc project is busy 6 hours a day on 21 working days.

........

Scenario	Ad hoc project	BI dashboards	ELT pipelines
Fair scheduling, all busy	200 slots	200 slots	200 slots
Ad hoc capped at 100 slots	100 slots	250 slots	250 slots
Ad hoc slot-hours per month, no cap	25,200	n/a	n/a
Ad hoc slot-hours per month, capped	12,600	n/a	n/a
Ad hoc slot-hours at $0.06, no cap	$1,512	n/a	n/a
Ad hoc slot-hours at $0.06, capped	$756	n/a	n/a

........

With all three projects busy and the reservation at its 600-slot maximum, fair scheduling gives each project 200 slots. A cap of 100 slots on the ad hoc project, the documented minimum, frees roughly 100 slots that the scheduler shares between the two remaining projects, so each moves toward 250. Because Google describes the cap as approximate and fair scheduling as eventually fair, these are target shares, and short-term allocations can differ.

The dollar rows measure how much reservation capacity the ad hoc project can draw on, priced at the Enterprise rate. They are not a forecast of the bill. Baseline slots are billed whether or not queries use them; at the same rate, 200 baseline slots for a 30-day month come to 144,000 slot-hours, or $8,640. Google's documentation does not say how a project cap interacts with autoscaling, so a reduction in autoscaled slot-hours after setting a cap should be confirmed in billing data before it is counted as a saving. Teams that compare editions with on-demand pricing can start from the BigQuery on-demand and editions pricing breakdown.

··········

ROUTING BI SERVICE ACCOUNTS WITH PRINCIPAL-BASED ASSIGNMENTS.

The principal property, generally available on the same date, changes which reservation a job lands on. The "Manage workload assignments" documentation lists the supported formats: users as principal://goog/subject/ followed by the email address, service accounts, workforce identity pool identities and workload identity pool identities. Groups are not among the documented formats.

CREATE ASSIGNMENT
  `ADMIN_PROJECT_ID.region-LOCATION.RESERVATION_NAME.ASSIGNMENT_ID`
OPTIONS (
  assignee = 'projects/PROJECT_ID',
  principal = 'principal://goog/subject/EMAIL_ADDRESS',
  job_type = 'QUERY');

BigQuery evaluates assignments from the project up through its parent folders to the organization. At each level, a principal-specific match is checked first, then a general assignment without a principal, and only then does the search move up a level. A project-level assignment without a principal therefore overrides a folder-level assignment with one, and Google recommends adding a user-specific assignment at the same project level when a particular identity must keep its routing. The default limit is 100 user-specific assignments per project.

A typical use is to separate the service account behind a dashboard tool from the analysts who query the same project, sending the dashboard identity to a reservation sized for refreshes while analysts stay on a shared or capped one. Creating assignments requires the bigquery.reservationAssignments.create permission on the administration project and the assignee, included in the BigQuery Admin, BigQuery Resource Admin and BigQuery Resource Editor roles. Google advises waiting at least five minutes after creating an assignment before running queries, because jobs that start earlier may be billed as on-demand, and assignments to a reservation without baseline, autoscaling or usable idle slots run as on-demand. Checking that a query reads only what it needs remains the first control, as covered in the guide to writing SQL with Gemini in BigQuery and checking the bytes it scans.

··········

WHAT TO CHECK BEFORE SETTING BIGQUERY PROJECT CAPS.

The reservation must run on Enterprise or Enterprise Plus, since the release notes exclude the Standard edition from both features. Admins should review current per-project slot usage before choosing values, because a maximum slots cap below a project's normal peak will slow its queries, and a concurrency cap set too low will queue jobs that previously ran in parallel. Scheduled pipelines with fixed deadlines are better candidates for a reservation default with a higher override than for a tight cap.

There is also a labeling difference in Google's own documentation. On November 12, 2026, the project caps section of the "Understand reservations" page still carried a Preview label with Pre-GA terms, while the release notes list the feature as generally available as of November 11. Organizations that require GA status for production settings may want the documentation to catch up, or confirmation from Google Cloud support, before relying on it.

The release fits a series of BigQuery changes this month that affect how analytics teams model and pay for queries, including graph measures that stop double counting after joins.

··········

BIGQUERY PROJECT CAPS AND PRINCIPAL ROUTING: WHAT GOOGLE HAS CONFIRMED.

Google's release notes confirm general availability of project caps and principal-based reservation assignments on November 11, 2026, for Enterprise and Enterprise Plus editions. The documentation confirms the two cap settings, the 100-slot minimum for maximum slots, the approximate nature of that cap, the admission-time behavior of the concurrency cap, the SQL, bq and console paths, and the 100 user-specific assignments per project limit for principal routing.

How much a cap reduces spending depends on the reservation's baseline, its autoscaling range, the edition and the workloads that compete for slots, and Google has not documented the interaction between caps and autoscaling. No separate price has been announced for either feature. The main gain is predictability, since a dashboard project no longer competes on equal terms with exploratory work and service accounts land on the reservation sized for them.

··········

·····

DATA STUDIOS

·····

datastudios.org