One of Enterprise edition’s key features is idle slot sharing: unused slots from one reservation automatically become available to others. This improves overall slot utilization without requiring manual rebalancing, but comes with trade-offs you need to understand.
How It Works
Suppose you have two reservations:
prod: 500 baseline slots, currently using 200dev: 100 baseline slots, currently using 150
The 300 idle slots in prod can be borrowed by dev, giving it access to up to 400 slots total (100 baseline + 300 borrowed).
The catch: if prod needs its slots back, it reclaims them instantly. Jobs in dev using borrowed capacity may slow down or get queued. This is the fundamental nature of idle slot sharing — borrowed capacity is preemptible. The owning reservation always has priority.
This preemption behavior protects the lending reservation. When the owning reservation needs its slots, they are returned immediately.
Requirements for Idle Slot Sharing
Reservations can share idle slots only if they meet all three conditions:
- They’re in the same admin project
- They’re in the same region
- They use the same edition
That first requirement is the one that trips teams up most often. If you accidentally create reservations across multiple admin projects, their slots remain completely isolated. The administration project pattern exists partly to avoid this mistake — centralizing all reservations in one admin project ensures they can all share idle capacity.
Also important: autoscaled slots are NOT shareable. Only baseline and committed slots participate in sharing. Autoscaled slots belong to the reservation that scaled them up and can’t be borrowed by others.
Configuration
Each reservation has an ignore_idle_slots setting:
false(default): Participates in sharing — can both borrow and lend idle slotstrue: Isolated, uses only its own capacity
The setting is per-reservation, so you can have some reservations participating in sharing while others are isolated. A common pattern: production and BI reservations participate in sharing (they benefit from each other’s off-peak capacity), while a compliance-sensitive reservation is isolated.
When Sharing Helps
The biggest benefit comes when reservations have complementary usage patterns. Classic examples:
- Production dbt runs from 4-7 AM; BI dashboards peak from 9 AM-6 PM. During off-hours, each can borrow the other’s idle capacity.
- US team queries during US business hours; EU team queries during EU business hours. Same slots serve both teams across time zones.
- Batch processing runs overnight; interactive analysis runs during the day.
Without idle sharing, you’d need to provision enough baseline for each workload’s peak independently. With sharing, you provision for each workload’s steady state and let idle capacity absorb moderate peaks. This can reduce total slot purchases significantly.
When to Disable Sharing
Consider setting ignore_idle_slots = true for:
- Proof-of-concept testing: You want to see how a reservation performs with exactly its allocated capacity, without borrowing from or lending to other reservations. This gives you accurate capacity planning data.
- Strict workload isolation: Regulatory or security requirements demand that certain workloads use only their dedicated resources.
- Capacity planning: When initially sizing reservations, disabling sharing helps you understand actual slot needs before optimizing. If a reservation performs fine with sharing but struggles without it, you know it’s undersized.
For most production use cases, leaving sharing enabled improves overall utilization. Non-critical workloads benefit without penalizing the lending reservation.
Idle Slots as Utilization Optimizer
Borrowed slots are not a substitute for properly sized reservations. A job running on borrowed capacity may slow mid-execution if the owning reservation reclaims its slots — the borrowing job’s active work units queue until they can be scheduled on the borrower’s own allocation.
Idle slot sharing improves utilization of existing slots by filling gaps. It does not replace baseline allocation for SLA-critical workloads. Development, batch processing, and workloads tolerant of variable performance are appropriate candidates for relying on borrowed capacity.