BigQuery Slot Reservations vs On-Demand Pricing: Which Model Actually Costs Less?
Every growing BigQuery deployment eventually reaches the same architectural crossroads.
Should the company continue paying for queries using On-Demand Pricing, or is it finally time to purchase BigQuery Reservations?
The internet is full of simplified recommendations.
“If you process a lot of data, buy slots.”
“If your workloads are predictable, use Reservations.”
“If you’re serious about analytics, move to capacity pricing.”
None of those statements are universally true.
More importantly, none of them answer the only question that matters to a CTO or CFO:
Will Reservations actually reduce our total cost of ownership?
This investigation began after a SaaS company operating across eleven countries received an unexpected proposal from an external consulting firm. The recommendation looked convincing.
Migrate all analytical workloads from On-Demand Pricing to BigQuery Enterprise Reservations. Estimated annual savings: 42%.
The proposal included attractive charts, capacity planning diagrams, and an implementation roadmap.
One detail was missing.
No one had validated the recommendation using the company’s actual workload.
The CTO postponed the migration and requested a three-week investigation based entirely on production telemetry.
At that point the platform processed approximately:
- 2.7 billion events every day
- 310 TB of active analytical storage
- 1,140 scheduled SQL jobs
- 2,900 interactive analyst queries per day
- 126 Looker dashboards
- 58 production Dataform repositories
Monthly BigQuery spending averaged $118,000.
Roughly 82% came from query execution.
Storage represented less than 11% of the bill.
The remaining costs consisted of streaming inserts, metadata operations, and other supporting services.
Nothing unusual appeared in Cloud Billing Export.
The consultants based their recommendation on one assumption.
The company processed large volumes of data.
Therefore Reservations would obviously be cheaper.
The engineering team decided to test that assumption.
Instead of looking at invoices, they analyzed every query executed during the previous six months.
Using INFORMATION_SCHEMA.JOBS_BY_PROJECT, they extracted:
- execution timestamp;
- slot consumption;
- bytes processed;
- execution duration;
- user type;
- workload category;
- concurrency.
More than 9.8 million completed jobs were loaded into a temporary analytical dataset.
The first visualization immediately challenged conventional wisdom.
Average daily query volume looked impressive.
Average hourly utilization did not.
Between 09:00 and 12:00, the platform processed enormous reporting activity.
From 18:00 until 06:00, utilization dropped dramatically except for scheduled ETL pipelines.
Several hours each night showed slot demand below 15% of daytime peaks.
That observation mattered because Reservations are purchased as capacity, not as individual query executions.
Unused capacity still costs money.
The engineers calculated the company’s concurrency profile.
| Percentile | Concurrent Slot Demand |
|---|---|
| 50th | 420 |
| 75th | 810 |
| 90th | 1,480 |
| 95th | 2,340 |
| Peak | 4,980 |
The numbers immediately exposed the challenge.
Sizing Reservations for average demand would produce queueing during business hours.
Sizing Reservations for peak demand would leave expensive capacity idle for most of the day.
Neither option appeared financially attractive.
The consultants had used average monthly query volume as their primary sizing metric.
The engineers believed that approach ignored the most important variable in BigQuery economics.
Time.
Not how much data the company processed.
But when it processed that data.
To test the theory, they built three independent financial models.
Model A assumed complete migration to Reservations.
Model B retained pure On-Demand pricing.
Model C combined Reservations for predictable production workloads with On-Demand pricing for interactive analysis and unpredictable demand.
Only one of those models would survive the evidence.
And the winner was not the one anyone expected.
The engineering team deliberately ignored vendor recommendations during the next phase of the investigation.
Instead, they replayed six months of production workload against three financial models.
The objective was not to estimate theoretical savings.
It was to determine which pricing model would have produced the lowest invoice using the company’s actual workload.
Every completed query was classified into one of five workload categories:
| Workload | Monthly Jobs | Predictability |
|---|---|---|
| Dataform transformations | 18,400 | Very High |
| Scheduled reporting | 9,700 | High |
| ELT pipelines | 7,900 | High |
| Looker interactive queries | 68,000 | Medium |
| Ad-hoc analyst queries | 2.8 million | Very Low |
The distinction proved critical.
Nearly 83% of total query volume came from analysts exploring data interactively. Individually, these queries were inexpensive, but collectively they created highly unpredictable spikes in concurrency.
By contrast, Dataform transformations and scheduled pipelines executed with remarkable consistency. Their start times varied by only a few minutes from day to day, making them excellent candidates for capacity-based pricing.
The engineers built the first model assuming a complete migration to Reservations.
To guarantee acceptable performance during business hours, capacity had to be provisioned for approximately 2,500 concurrent slots. Lower numbers caused unacceptable queueing during reporting peaks.
The simulation produced an unexpected result.
Average utilization of purchased capacity reached only 43% over a full month.
More than half of the reserved computing power remained idle most of the time.
The company would pay for it anyway.
The second model retained pure On-Demand pricing.
Financially, it looked attractive because there was no unused capacity.
Operationally, it exposed another problem.
During the busiest reporting periods, analysts occasionally waited 40–90 seconds before receiving results because thousands of interactive queries competed for the same shared resources.
Performance complaints had already become one of the most common support requests.
Neither model solved both problems simultaneously.
The hybrid approach produced a very different picture.
Scheduled production workloads—including Dataform, ELT jobs, reconciliation processes, fraud calculations, and executive reporting—were assigned to dedicated Reservations.
Interactive analysis remained On-Demand.
The engineers then replayed the complete production workload.
The comparison looked like this.
| Pricing Model | Monthly Cost | Avg. Dashboard Response | Peak Queue Time |
| On-Demand Only | $118,000 | 6.4 sec | 84 sec |
| Reservations Only | $109,700 | 2.1 sec | 3 sec |
| Hybrid Model | $92,600 | 2.5 sec | 6 sec |
The consultants had recommended Reservations everywhere.
The evidence suggested something very different.
Reservations were highly effective where workloads were predictable.
They became increasingly inefficient as demand became random.
The company wanted to verify that the projected savings would survive real production traffic.
Instead of migrating the entire platform, one Reservation was created for approximately 35% of scheduled workloads.
The experiment ran for six weeks.
Cloud Billing Export showed remarkably close agreement with the simulation.
Average monthly spend decreased by roughly 21%.
Interactive query performance remained stable because unpredictable workloads continued using On-Demand resources.
Production pipelines became more consistent because reserved capacity protected them from daytime query spikes.
Unexpectedly, another benefit appeared.
Engineers could now identify which departments consumed analytical capacity because Reservations were assigned by workload rather than by project.
Marketing.
Finance.
Fraud Detection.
Data Science.
Each department received its own utilization metrics.
Cost discussions became significantly more productive.
Instead of asking why the BigQuery invoice had increased, executives began asking why one department consistently consumed three times more analytical capacity than another while delivering comparable business value.
The pricing model had become a management tool.
The investigation also disproved another widespread assumption.
Several teams believed purchasing more slots would automatically make expensive SQL cheaper.
It did not.
Reservations improve capacity planning.
They do not reduce the amount of data scanned.
Poorly written SQL remained expensive regardless of the pricing model.
One weekly transformation still scanned 16.2 TB because it ignored partition pruning.
Reservations made it finish sooner.
They did not make it economical.
That distinction became a permanent engineering guideline.
Optimize SQL first. Optimize pricing second.
Changing the commercial model before improving workload efficiency simply locks inefficient architecture into a different billing structure.
After six months, the migration strategy became official.
Approximately 65% of predictable workloads ran on Reservations.
Interactive analysis, experimentation, incident investigations, and exploratory SQL remained On-Demand.
Annual savings were estimated at just over $300,000.
More importantly, the company avoided purchasing approximately 40% more reserved capacity than it actually needed—capacity that the original consulting proposal had recommended.
The post-project review summarized the lesson in a single sentence.
Reservations are not a discount program.
They are a capacity management strategy.
Organizations that understand the difference usually save money.
Organizations that do not often commit themselves to years of paying for idle compute.
Evidence Collected
- Cloud Billing Export
INFORMATION_SCHEMA.JOBS_BY_PROJECT- BigQuery Reservation utilization metrics
- Cloud Monitoring slot utilization
- Looker query history
- Dataform execution schedules
- Concurrency analysis by workload category
Executive Recommendations
- Measure workload predictability before evaluating Reservations.
- Never size Reservations using average monthly query volume.
- Separate predictable production workloads from interactive analysis.
- Optimize inefficient SQL before changing the pricing model.
- Review Reservation utilization quarterly to avoid paying for idle capacity.
The Question Every CTO Should Ask
“Are we buying computing capacity because our workloads require it—or because we assume more slots automatically mean lower cloud costs?”
We evaluate your current data setup to eliminate performance bottlenecks, refactor complex pipelines, and prevent unexpected cloud costs. Schedule a BigQuery Migration & Architecture Audit to ensure your data infrastructure is scalable, secure, and cost-efficient.