BigQuery cost is two separate problems wearing one bill: storage, priced per gigabyte per month, and compute, priced either on demand by bytes scanned or on capacity through reserved slots. The largest compute lever is reducing bytes scanned through partitioning, clustering, and selecting only the columns you need, because on demand cost is directly proportional to data read. The second is choosing the right compute model: capacity pricing for heavy, steady query volume where a fixed slot cost beats the sum of per scan charges, and on demand for spiky or light usage where you pay nothing between queries. Get layout and pricing model right and BigQuery spend tracks the work it does rather than the data it happens to hold.
This is the end to end view: storage tiers, the two compute models, the layout that cuts bytes scanned, and the guardrails that keep it from drifting.
Where does BigQuery spend actually go?
Storage is the quieter half. BigQuery prices active storage and long term storage differently, with data that has not been edited for a while automatically moving to a cheaper long term rate. That means stale tables nobody queries still cost money to hold, so lifecycle on datasets matters. Compute is the louder half and the one teams notice. On demand compute charges for the bytes a query scans, with no charge for query complexity, so a query that scans a terabyte costs many times one that scans a few gigabytes for the same answer. Capacity compute charges for reserved slots over time regardless of individual query size. Knowing which half your bill comes from decides where you spend effort.
What cuts bytes scanned the most?
On demand cost is a direct function of data read, so layout is the lever.
| Technique | Mechanism | Effect on bytes scanned |
|---|---|---|
| Partitioning | Splits a table by date or an integer range so queries prune to the relevant partitions | Large reduction on filtered queries |
| Clustering | Sorts data within partitions on common filter columns so the engine reads fewer blocks | Further reduction on selective queries |
| Select needed columns | Avoids select star, since BigQuery is columnar and only reads referenced columns | Reads a fraction of the row width |
| Summary tables and materialized views | Precompute repeated aggregations so queries scan the small result, not the raw data | Repeated heavy queries become cheap reads |
Because BigQuery stores data by column, select star is the single most expensive habit an analyst has: it forces the engine to read every column when the query needed three. Partitioning plus clustering plus column selection compound, and together they routinely take bytes scanned, and therefore on demand cost, down to a fraction of the original.
On demand or capacity, and how do you keep it from drifting?
The pricing model decision mirrors any commitment decision. On demand rewards variability: you pay per scan and nothing between queries, which is cheapest for spiky, exploratory, or light workloads. Capacity rewards predictability: you reserve slots billed by time, which is cheapest when heavy, steady query volume would otherwise run up a large sum of per scan charges, and it makes spend predictable. Many estates run a hybrid, capacity for the steady production analytics and on demand for ad hoc exploration. Whatever the model, set guardrails: per query bytes scanned limits stop a runaway select star, project level controls cap exposure, and routing teams into separate reservations or billing projects makes scan volume attributable.
Look at your largest queries by bytes scanned. If they scan raw, unpartitioned tables or run select star, the cost is layout, not query volume, and partitioning plus column selection will remove most of it before you change the pricing model.
A worked example
A Fortune 500 retailer ran a predictable daily analytics load on BigQuery on demand against large, unpartitioned tables with select star common in dashboards. We partitioned and clustered the heavy tables, rewrote the dashboard queries to select only needed columns, added summary tables for the repeated aggregations, then moved the steady production load onto capacity pricing while leaving ad hoc analysis on demand. Bytes scanned fell to a fraction of the original, the predictable load became a fixed slot cost, and total BigQuery spend dropped substantially while dashboards loaded faster. Figures are verified against billing data and anonymized.
Where this fits
The pricing model decision is covered in depth in on demand versus capacity pricing in BigQuery, and the wider data platform economics are in the economics of GCP data lakes. The full method sits in the GCP cost optimization guide, with the cross cloud data view in the cross cloud cost optimization guide.
Frequently asked questions
How is BigQuery billed?
How do you reduce BigQuery cost?
On demand or capacity pricing for BigQuery?
Take the next step on your cloud spend
We are an independent buyer side advisory that cuts public cloud spend across AWS, Azure, GCP, and OCI. We hold over $2.4B in annual cloud spend under management, take zero provider commissions, and deliver a 31 percent median reduction in the first 90 days. Our guarantee is simple: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk to you.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.