Trusted Digital Transformation Partner
BigQuery Cost Optimization for Indian Enterprises: On-Demand vs Slots & the FinOps Playbook (2026)
- By Virender Kumar, Head of Cloud & Database
- Published Sep 09, 2026
BigQuery's on-demand pricing charges per byte scanned, so an unpartitioned table and a SELECT * habit are the two most expensive mistakes an analytics team can make. Partitioning and clustering typically cut scan costs 60-90% on large tables. Flat-rate/autoscaling slot commitments make sense once monthly on-demand spend is predictable and substantial — not before. Most BigQuery cost overruns are a query-design problem, not a pricing-model problem.
BigQuery's serverless pricing model is genuinely simple to understand and genuinely easy to get wrong in practice. On-demand pricing charges for the data scanned by a query, not the data returned — which means a poorly written query against a large, unpartitioned table can cost 50x what a well-written equivalent query costs, with identical output. Most BigQuery bill shock is not a pricing problem. It is a query-design and table-design problem that pricing merely makes visible.
On-Demand vs Flat-Rate (Slot Reservations) — When Each Makes Sense
| Model | How it's billed | Best for |
|---|---|---|
| On-demand | Per TB of data scanned by each query | Unpredictable or low query volume; teams just getting started; workloads with genuine spikes |
| Flat-rate / Capacity-based (slots) | Fixed monthly cost for a committed number of query-processing slots | Predictable, high query volume where on-demand spend already exceeds the equivalent slot commitment cost |
| Autoscaling slots (BigQuery Editions) | Baseline slots plus autoscaled capacity billed per second during bursts | Variable but substantial workloads wanting cost predictability without over-committing to a fixed reservation |
The mistake we see most often is committing to a flat-rate slot reservation before establishing what on-demand spend actually looks like at query-optimised baseline. Fix the query and table design first — the slot commitment you need afterwards is often smaller than the one you would have bought first.
The Five Most Common BigQuery Cost Mistakes
SELECT *instead of naming columns — BigQuery's columnar storage means it only needs to scan the columns actually referenced. Selecting every column on a wide table scans and bills for data the query never uses.- No partitioning on large, frequently-filtered tables — without partitioning by date (the most common case) or another logical key, every query scans the entire table even when it only needs the last seven days.
- No clustering on high-cardinality filter columns — clustering co-locates related rows physically, so a filtered query reads fewer blocks. Skipping it on a table regularly filtered by customer ID or region leaves real savings unclaimed.
- Materialised views and cached results left unused — repeated identical or near-identical queries against the same base data are strong candidates for a materialised view, which BigQuery can serve from instead of rescanning the source table.
- No cost controls on ad-hoc analyst access — a single unbounded exploratory query from an analyst against an unpartitioned multi-terabyte table can cost more than a month of well-designed production queries. Custom cost controls and per-user/per-project quotas catch this before the bill does.
Partitioning and Clustering as Cost Controls, Not Just Performance Tuning
Partitioning and clustering are usually framed as query-performance features. For cost, they matter more: a query against a date-partitioned table filtered to the last 30 days scans roughly 30 days of data, not the full history — on a multi-year table, that is often a 90%+ reduction in bytes scanned, which is a 90%+ reduction in on-demand cost for that query. This is the highest-leverage, lowest-effort optimisation available on most BigQuery workloads, and it is frequently skipped simply because the table worked fine without it at small scale and nobody revisited the design as data volume grew.
A Practical BigQuery Cost Governance Checklist
- Set custom quotas / maximum bytes billed per query for ad-hoc and analyst access
- Partition every table over a few GB by date or another natural filter key; add clustering on top for high-cardinality filter columns
- Review the BigQuery cost breakdown by project and user monthly — a single runaway query is easy to miss in an aggregate bill
- Use
--dry_runto estimate bytes scanned (and therefore cost) before running an expensive query against production data - Reassess flat-rate/slot commitments quarterly against actual optimised on-demand-equivalent spend, not the number from when the commitment was first purchased
ROSTAN's GCP Practice
ROSTAN Technologies runs Google Cloud Cost Optimization — including BigQuery-specific query and schema review — as a standalone engagement. We audit actual usage against Committed Use Discounts, partitioning/clustering opportunities, and slot commitment sizing, without needing to have built your GCP environment first.
Explore our Google Cloud Services or request a free BigQuery cost review.
EBS to OCI Migration
We migrate workloads to Oracle Cloud Infrastructure, AWS and Azure — and tell you honestly which one fits.
See our cloud servicesFrequently Asked Questions
Have questions about Oracle, AWS or Cloud?
Talk to our certified experts — free consultation, no commitment.
Recent Post
Planning a cloud move?
OCI, AWS or Azure — the architectural answer and the financial answer are rarely the same. Tell us the workload and we will model it on your real numbers before you commit.
