Bigquery Reservation Autoscaling Idle Slot Priority

What BigQuery Reservation Priority and Autoscaling Is

BigQuery Editions use a hierarchical slot provisioning mechanism that optimizes performance and cost efficiency across multi-tenant reservation architectures. When jobs demand more compute capacity than a single reservation's baseline, BigQuery allocates capacity according to a strict priority hierarchy: Baseline slots, followed by Idle slot sharing from sibling reservations in the same region and edition, and finally Autoscaling slots up to the reservation's configured maximum size.

How It Meets the Requirements

1. Step 1 (Own Baseline Allocation): BigQuery immediately utilizes all 600 baseline slots configured in the batch_etl reservation.
2. Step 2 (Idle Slot Sharing): Because ignore_idle_slots is set to false on both reservations within the same edition and region (us-central1), batch_etl borrows the 400 idle baseline slots from the inactive reporting_bi reservation before spinning up autoscaling slots. This brings total available capacity to 1,000 slots.
3. Step 3 (Autoscaling Activation): To meet the remaining 100 slot requirement (1,100 total needed - 1,000 available), BigQuery dynamically provisions 100 autoscale slots in batch_etl.
4. Billing Calculation: The customer is billed for the fixed 600 baseline slots (batch_etl) and 400 baseline slots (reporting_bi) at standard baseline/commitment rates, plus the hourly autoscaling rate specifically for the 100 upscaled slots for the duration of the scaling event.

Key Advantages

• Cost Optimization: Prioritizing idle baseline borrowing avoids unnecessary autoscale compute costs when existing paid baseline capacity is sitting idle.
• Fast Provisioning: Baseline and borrowed idle slots are immediately available without cold-start provisioning latency.
• Controlled Scale: Autoscaling seamlessly covers remaining bursts up to the maximum reservation boundary.
• Fair-Share Return: If jobs arrive in reporting_bi, borrowed idle slots are preemptively returned, prompting batch_etl to autoscale further if needed.

Why This Is Optimal

This allocation sequence minimizes operational expenditure by exhausting already-purchased baseline capacity across the organization before invoking dynamic autoscaling pricing.