BigQuery’s idle slot sharing (i.e. how BigQuery distributes idle slots across reservations) is changing on April 1, 2026. This post dives into how the current distribution model currently works, the advantages of the new default, and whether you should enable the change on your existing admin project before the deadline.

If you run BigQuery with multiple reservations, idle slots are quietly doing significant work. When a reservation isn’t using all its baseline capacity, those unused slots get redistributed to other reservations that need them. The problem: Google’s current default for deciding who gets those idle slots has a systematic flaw. A reservation with 10 assigned projects claims up to 10× the idle capacity of a reservation with 1 project — not because it needs more, but because of how the math works. Starting April 1, new admin projects get a better default. Here’s what changes, who’s affected, and what to do about it.

What are idle slots in BigQuery, and why does their distribution matter?

BigQuery slots are the unit of compute capacity BigQuery uses to execute queries. When you set up a reservation, you define a baseline — a number of slots always allocated and always billed, whether queries are running or not. When a reservation isn’t fully using its baseline, the leftover capacity becomes idle slots: spare compute that BigQuery redistributes to other reservations of the same edition (e.g. enterprise slots only to enterprise reservations) in the same admin project within the same region.

Idle slots are effectively free, since you’ve already paid for the baseline capacity sitting unused: when another reservation borrows it, no additional charges apply. For teams running zero- or low-baseline reservations, idle slot access can substantially cut costs — borrowed idle slots displace what would otherwise be billed autoscale usage.

The catch: idle slot access is not guaranteed. It depends on what other reservations have sitting unused at that moment, and on who BigQuery decides to give it to. That second question is what the April 2026 change addresses.

What is project-based fairness, and why can it create problems?

Under the current default (what Google calls project-based fairness), BigQuery distributes idle slots equally among all projects across the entire admin project, regardless of which reservation those projects belong to.

Here’s why that may cause problems.

Say your admin project has two reservations:

• prod: 1 project running business-critical dashboards and reporting pipelines
• dev: 10 projects used by engineering teams for experimentation and development

With 1,100 idle slots available in the pool, project-based fairness gives each of the 11 projects an equal share: 100 idle slots each. prod’s single project gets 100 idle slots. dev’s 10 projects collectively receive 1,000.

The result: your development environment (which has more lenient latency requirements and can tolerate slowdowns) quietly consumes 10× the idle capacity that your production workloads receive. Nobody configured this intentionally. It’s the default, and most teams don’t even know it’s happening.

The problem compounds with scale. The more projects a reservation contains, the larger its share of the idle pool, regardless of how critical or demanding its workloads are. Teams that use many projects for cost attribution, team isolation, or environment separation inadvertently starve reservations that happen to have fewer projects but more important jobs.

How does BigQuery reservation fairness fix the problem?

Google’s updated model — BigQuery reservation fairness — changes the distribution in two steps:

1. Idle slots are first distributed evenly across reservations
2. Within each reservation, those idle slots are then distributed fairly among its projects

Using the same scenario: 1,100 idle slots, prod (1 project), dev (10 projects). Under reservation-based fairness, each reservation receives 550 idle slots. prod’s single project gets the full 550. dev’s 10 projects split 550 among them — 55 each.

Production now gets 5.5× more idle capacity than it did under the previous default, without changing a single reservation configuration.

Two things to be aware of:

• Demand-driven only: Idle slots only flow to reservations where queries are actively running. A reservation with no active jobs doesn’t receive idle capacity, regardless of fairness mode.
• Enterprise and Enterprise Plus editions only: Standard Edition doesn’t support idle slot sharing, so this change doesn’t apply to Standard.

What is actually changing in BigQuery on April 1, 2026?

Google is making two specific changes to defaults:

New admin projects default to reservation-based fairness. Any admin project you create after April 1, 2026 will use reservation-based fairness for idle slot distribution automatically. No manual configuration needed.

The UI default for new reservations shifts to “Most predictable.” Reservation-based fairness unlocks a new set of per-reservation controls called scaling modes. Scaling modes are explicit settings for whether a reservation can borrow idle slots, autoscale, or both, with a hard cap on total slots (you can set the baseline and the max slots for autoscale). Under the new default (“Most predictable”), new reservations will have bounded, capped slot consumption (a total cap set for baseline + borrowed + autoscale) rather than the previous behavior (“Most variable”, baseline + autoscale max slots). If you want the old behavior for a specific reservation, you’ll need to select it manually during setup.

Existing admin projects are unaffected. Your current setup stays exactly as configured until you explicitly enable reservation-based fairness. There is no automatic migration, and Google’s notification is explicit: no immediate action is required for existing admin projects or reservations.

Does this change of idle slot distribution affect your setup?

The impact depends on how your reservations are organized. Two questions give you a fast read:

How many projects are assigned to each reservation?

If your reservations all have roughly equal project counts, the distribution is already close to even. In this case, project-based and reservation-based fairness produce similar results. The more asymmetric your project counts, the more meaningful the change is.

Run this against your admin project to see current project distribution per reservation:

SELECT
  reservation_name,
  COUNT(DISTINCT assignee_id) AS project_count
FROM
  `your-admin-project.region-your-region`.INFORMATION_SCHEMA.ASSIGNMENTS
WHERE
  assignee_type = 'PROJECT'
GROUP BY
  reservation_name
ORDER BY
  project_count DESC;

Note: This query only counts direct project assignments. If you use folder-level assignments, validate the results against your project hierarchy, as the effective distribution may occur across the projects within the folder.

If one reservation has 8-10 projects and another has 1-2, reservation-based fairness would significantly rebalance how idle slots flow between them.

Which reservations are configured to borrow idle slots?

A reservation with ignore_idle_slots = false can borrow idle capacity from other reservations. One with ignore_idle_slots = true never borrows — and for those, idle slot distribution is irrelevant since they don’t participate in the pool. (Note that this setting only controls whether the reservation borrows idle slots, but it will always lend its own idle slots to others).

Here’s how to check your current configuration for ignoring idle slots:

SELECT
  reservation_name,
  slot_capacity AS baseline_slots,
  ignore_idle_slots,
  scaling_mode,
FROM
  `your-admin-project.region-your-region`.INFORMATION_SCHEMA.RESERVATIONS
ORDER BY
  reservation_name;

Reservations with ignore_idle_slots = false and low slot_capacity are the ones most sensitive to distribution changes. If any of these sit in a low-project-count reservation next to high-project-count neighbors, they’re likely receiving less idle capacity than they would under reservation-based fairness.

The scaling_mode column shows SCALING_MODE_UNSPECIFIED for reservations that haven’t yet adopted the new scaling mode framework. These are running under the traditional ignore_idle_slots behavior. Once reservation-based fairness is enabled on the admin project, you can configure explicit scaling modes per reservation.

Should you enable BigQuery reservation fairness before April 1?

While BigQuery reservation fairness becomes the default for new projects soon, you have the option to enable it before the switch for your existing projects.

Enable BigQuery reservation fairness now if:

• Your reservations have meaningfully asymmetric project counts (more than a 2–3× difference)
• A production reservation with few assigned projects depends on idle slot access for throughput above its baseline — and if that baseline is zero, an unfavorable distribution doesn’t just slow queries down, it stalls them entirely
• You want more precise control over the reservations’ scaling behavior by configuring scaling modes (IDLE_SLOTS_ONLY, AUTOSCALE_ONLY, ALL_SLOTS), as reservation-based fairness is a prerequisite for all of them

Wait and observe if:

• Your project counts across reservations are roughly balanced and the current distribution is working fine
• You’re unsure about current idle slot consumption patterns and don’t want to change a live setup without a baseline measurement first
• You’re planning to create a new admin project after April 1 anyway (new projects will automatically get the updated default)

No action needed if:

• You’re on Standard Edition: idle slot sharing isn’t supported, so this change doesn’t apply
• All your reservations have ignore_idle_slots = true — if nobody is borrowing, distribution doesn’t affect anything

What to check before enabling reservation-based fairness?

If you decide to enable it on an existing admin project, go through this before flipping the switch.

1. Enable fairness at the admin project level:

ALTER PROJECT `your-admin-project`
SET OPTIONS (
  `region-europe-west3.enable_reservation_based_fairness` = true
);

Replace europe-west3 with your region.

2. Identify which reservations borrow idle slots. Reservations with ignore_idle_slots = false will see changed idle slot distribution immediately. Know which direction each reservation will move (more or less idle capacity than before) prior to enabling.

3. Zero-baseline reservations need the most attention. A zero-baseline reservation set to borrow idle slots has no guaranteed capacity at all: it runs entirely on redistributed idle slots. Under reservation-based fairness, it will receive a predictable share proportional to the number of reservations in the admin project, rather than the project-count-weighted share it may have had before. This could mean more or less capacity depending on your setup.

4. Scaling modes become available once fairness is enabled. You can then explicitly configure each reservation’s scaling behavior: IDLE_SLOTS_ONLY (borrows idle capacity only, no autoscale billing), AUTOSCALE_ONLY (autoscales only, never borrows), or ALL_SLOTS (borrows idle capacity first, autoscales for anything additional, up to a hard cap). These modes also let you set a max_slots ceiling on total consumption, making costs bounded and predictable per reservation.

How does Rabbit help you see idle slot patterns before you change anything?

The practical challenge with this decision is that INFORMATION_SCHEMA shows you configuration, not actual idle slot flows. You can see that a reservation has ignore_idle_slots = false, but you can’t easily see how many idle slots it’s actually receiving versus lending out, or how that compares to what it would receive under reservation-based fairness.

Rabbit’s reservation-level visualization breaks usage into consumed, borrowed, and lent components for each reservation. Before enabling reservation-based fairness, you can see exactly which reservations are over-consuming idle capacity relative to their project count, which are being underserved, and how significant the rebalancing would be. That makes the opt-in decision concrete rather than a judgment call.

If you’re also considering adopting scaling modes as part of the April transition, the Reservation Planner analyzes historical slot usage to recommend the right combination of baseline and max slots for each reservation.

The April 1 change doesn’t force anything. For teams with balanced, symmetric reservation setups, it’s a neutral event. But if you have meaningful asymmetry (for example, a development environment spread across 10 projects sitting in the same admin pool as a single-project production reservation) the new default is a significant improvement that you don’t need to wait until April to get.

For a deeper look at how scaling modes, idle slot borrowing, and autoscaling interact once reservation-based fairness is enabled, see BigQuery Reservation Scaling Modes: What They Are and How to Choose the Right One.

For the mechanics of how autoscaling and idle slots interact in the underlying billing model, see BigQuery Reservations: How Does Autoscaling Really Work?