Technical guide
How partitioning and clustering reduce BigQuery bytes scanned
A scenario-based guide to lowering on-demand BigQuery analysis cost without hiding performance and maintenance tradeoffs.
Updated 2026-09-05 · Data verified2026-09-05
A worked scenario
Suppose a 10 TiB events table receives queries that need one day from a 100-day history. A query without effective pruning might scan 10 TiB. A date-partitioned table that prunes to one evenly sized partition might scan about 0.1 TiB before column selection and clustering effects. At the same analysis rate, the modeled scan charge falls by roughly 99% for that query.
Partition first for predictable filters
Choose a partition key present in common filters and require partition filters where appropriate. Pruning depends on the actual query predicate; creating partitions alone does not guarantee fewer billed bytes.
Use clustering for selective access within partitions
Clustering can reduce blocks read when filters align with clustered columns. Results depend on data distribution and table size. Validate with dry-run byte estimates and job statistics instead of claiming a fixed savings percentage.