On-demand vs slots: the SME decision boundary

On-demand is the default for an SME warehouse. Reservations become useful when recurring workloads need a compute contract that shared on-demand execution can’t provide cleanly.

Capacity pricing isn’t a maturity stage or the adult version of BigQuery. Choose it for workload behavior: predictability, isolation, routing, and enough repeated demand to justify owning the lane.

Stay on-demand while variability is an advantage

Early warehouses mix exploration, model development, occasional backfills, scheduled transformations, and modest reporting. Demand is irregular, boundaries are still moving, and paying for bytes processed keeps the operating model simple.

At this stage, invest in cost guardrails, partitioning, labels, and job visibility. Those controls expose which workloads are becoming stable without forcing the platform to predict its capacity shape too early.

Sporadic expensive queries don’t automatically justify reservations. A bad table model remains bad under either pricing model, and a rare backfill can be cheaper to run intentionally than to carry capacity for all month.

Move when workloads need distinct treatment

The useful trigger is a recurring workload with a requirement the current lane can’t express well.

Examples include:

• dashboard traffic needs controlled latency while analysts explore
• scheduled transformations need predictable completion windows
• a service-facing query path has become a production dependency
• one workload class repeatedly interferes with another
• spend is stable enough that capacity planning can improve predictability

Name the workload before buying capacity. Measure its job count, slot use, concurrency, queue time, latency, and schedule. Then decide which project or folder assignment will route it to the reservation.

If the team can’t say which jobs belong in the lane, the reservation won’t create the boundary. It will merely make the ambiguity billable in a different unit.

Mix models instead of converting the warehouse

BigQuery lets projects remain on-demand while other projects are assigned to reservations in the same location. Use that flexibility.

A small setup often needs only two effective lanes:

on-demand
  analyst exploration
  development
  irregular backfills

capacity-based
  scheduled production transforms
  repeated reporting or serving workloads

Some teams split reporting and batch later because their latency and queue requirements diverge. Do that after measured interference appears, not because three boxes look more architectural than two.

Project and reservation assignments should follow workload class rather than department. Finance exploration and engineering exploration have more in common with each other than either has with an executive dashboard.

Economics matter after the workload is legible

Compare expected on-demand spend with the capacity configuration needed to meet performance and isolation requirements. Include autoscaling minimums, commitments if any, idle periods, and the operational cost of managing assignments and limits.

The cheapest monthly estimate isn’t always the best decision. A reservation may be worth more because it protects a reporting SLO or keeps batch work from competing with interactive users. Conversely, lower theoretical unit cost doesn’t help when demand is too bursty to use the capacity well.

Use historical job data and test with a bounded workload. Capacity recommendations can inform the starting point, but the system still needs monitoring after the move.

Reservations don’t repair the serving model

Before assigning dashboard traffic to slots, inspect whether the dashboard should keep querying live. Repeated aggregations may belong in scheduled tables, materialized views, or extracts. Query fan-out may come from chart-level logic. An inefficient serving path can consume any amount of isolated capacity offered to it.

The same applies to batch. A model that rewrites unnecessary history doesn’t become disciplined because its slots are predictable.

Fix obvious workload shape first. Buy isolation for the work that remains.

When to stay or move

Stay on-demand when production pressure is light, irregular, or poorly classified. Move a named workload to reservations when its repeated demand, latency, completion, or isolation requirement is worth a dedicated compute policy.

Revisit the decision when the workload changes. A reservation that once protected reporting may become unnecessary after precomputation. An on-demand project may earn a lane after a service begins relying on it.

Choose the pricing model that makes the current workload easier to operate. Sophistication doesn’t decide it.