BigQuery cost optimization: a deep dive on query and storage spend

Quick answer

BigQuery cost has two parts: query processing and storage. Query cost under on-demand pricing is billed by bytes scanned, so the biggest levers are partitioning and clustering tables (so queries scan less), selecting only needed columns (never SELECT star), and filtering on partition keys. For heavy, predictable query volume, capacity (slot) pricing can beat on-demand. Storage cost drops when you let long-untouched data fall to the cheaper long-term storage rate and prune data you do not need. Most BigQuery waste is scanning far more data than a query needs.

BigQuery makes it trivially easy to scan terabytes, which is exactly why bills surprise people. Under on-demand pricing you pay for the bytes a query reads, so a careless query over a large unpartitioned table can cost real money in seconds. The good news: a few disciplined habits cut query cost dramatically, and storage has its own simple levers.

The two cost components

Component	Billed on	Main lever
Query (on-demand)	Bytes scanned	Scan less: partition, cluster, select columns
Query (capacity)	Slots reserved	Right-size slot commitment to workload
Active storage	Bytes stored, recently modified	Prune and partition-expire data
Long-term storage	Bytes untouched for a while, cheaper rate	Let cold data age into it automatically

Query cost dominates most BigQuery bills, and under on-demand pricing it is entirely about how many bytes a query scans. Storage is usually the smaller share and partly self-optimizing, since data untouched for long enough automatically drops to the cheaper long-term rate.

Scan less: the core query lever

The single most effective habit is scanning less data. Partition tables (by date is the common choice) so queries that filter on the partition key read only the relevant partitions, not the whole table. Cluster tables on commonly filtered columns so BigQuery can skip blocks. Never use SELECT star; select only the columns you need, since column pruning cuts bytes scanned directly. Preview data with the table preview rather than a query. Together these can turn a full-table scan into reading a small slice.

On-demand versus capacity pricing

On-demand pricing charges per byte scanned and needs no commitment, ideal for spiky or unpredictable query volume. Capacity (slot) pricing reserves query processing capacity for a flat rate, which can be far cheaper for heavy, steady query volume where on-demand byte charges would exceed the cost of reserved slots. Estimate your monthly bytes scanned and compare it to a slot commitment; high, predictable volume usually favors capacity, while light or bursty use favors on-demand. This mirrors the commitment logic in reservations.

Controlling storage and preventing surprises

For storage, set partition expiration so old data is dropped automatically, delete tables and datasets you do not need, and let cold partitions age into long-term storage rather than rewriting them (a modification resets the clock). To prevent runaway query cost, set per-query and per-user bytes-scanned limits (custom quotas) so a runaway query cannot scan unlimited data, and set budget alerts on the project. BigQuery is one of the services that can quietly become a top cost driver, so treat it like the biggest cost drivers elsewhere and watch it. Because query and storage patterns are shaped at design time, reviewing them against the resource catalog and a good FinOps culture keeps scans efficient by default.

FAQ

What determines BigQuery cost?

Two components: query processing and storage. Under on-demand pricing, query cost is billed by bytes scanned, so it depends on how much data your queries read. Under capacity pricing, you pay for reserved slots. Storage is billed by bytes stored, split into active storage and a cheaper long-term rate for data untouched for a while. Query cost dominates most bills.

How do I reduce BigQuery query cost?

Scan less data. Partition tables (often by date) so queries filtering on the partition key read only relevant partitions, cluster tables on commonly filtered columns so BigQuery skips blocks, and select only the columns you need rather than SELECT star. Preview data with the table preview instead of a query. These habits can turn a full-table scan into reading a small slice.

Should I use BigQuery on-demand or capacity pricing?

Use on-demand (billed per byte scanned, no commitment) for spiky or unpredictable query volume. Use capacity (slot) pricing, which reserves processing capacity for a flat rate, for heavy, steady query volume where per-byte charges would exceed the cost of reserved slots. Estimate your monthly bytes scanned and compare it to a slot commitment to decide which is cheaper.

What is BigQuery long-term storage?

A cheaper storage rate that applies automatically when a table or partition has not been modified for a while (roughly 90 days). You do nothing to get it, and it cuts storage cost for cold data. The catch is that any modification resets the clock back to the active storage rate, so avoid needlessly rewriting cold partitions if you want them to stay in long-term storage.

How do I stop a runaway BigQuery query from costing a fortune?

Set per-query and per-user bytes-scanned limits using custom quotas so no single query or user can scan unlimited data, require partition filters on large tables, and avoid SELECT star. Set budget alerts on the project so unexpected spend is caught early. Reviewing the estimated bytes a query will scan before running it also prevents accidental full-table scans.

Does C3X help with BigQuery cost?

C3X prices data infrastructure before deploy against a live catalog, so choices that shape BigQuery cost (dataset and table configuration, capacity commitments) are visible at design time. Combined with query discipline (partitioning, clustering, column pruning) and budget alerts, that keeps BigQuery from quietly becoming a top cost driver you only notice on the bill.

What to do next

Keep data-warehouse cost visible before it grows. C3X prices your infrastructure against a live resource catalog.