A BigQuery materialized view is a precomputed, automatically maintained query result that turns a repeated heavy aggregation into a cheap read: instead of scanning the large base table every time, eligible queries scan the small precomputed result, and BigQuery can substitute the view transparently without changing the query. As a cost move it pays off exactly when the same expensive aggregation runs many times against base data that changes only moderately, because the bytes scanned per query collapse while the maintenance cost of keeping the view current stays modest. The discipline is to point materialized views at your most repeated, most expensive aggregations rather than at everything, since a view over rapidly churning data can cost more to maintain than it saves.
This explains the mechanism, when a materialized view beats a summary table, and how to pick the views that actually cut the bill.
How does a materialized view cut cost?
On demand BigQuery charges by bytes scanned, so a dashboard that aggregates a billion row table every few minutes scans that table on every refresh, repeatedly, for an answer that barely changes. A materialized view precomputes that aggregation once and maintains it incrementally as new data arrives, so each subsequent query reads the small materialized result instead of the full base table. Because BigQuery can rewrite eligible queries to use the view automatically, even queries written against the base table can benefit without being rewritten. The bytes scanned per query fall from the size of the raw table to the size of the aggregate, which for a heavy aggregation is a large reduction, repeated on every read.
When does a materialized view beat a summary table?
Both precompute results to avoid rescanning raw data, but they differ in maintenance and control.
| Dimension | Materialized view | Scheduled summary table |
|---|---|---|
| Maintenance | Automatic and incremental as base data changes | Explicit; you schedule and own the refresh |
| Query substitution | Transparent; eligible queries are rewritten to use it | Manual; queries must target the summary table |
| Transformation complexity | Supports a defined set of aggregation patterns | Any SQL you can schedule |
| Best for | Frequent reads, moderately changing data, queries you do not control | Complex transforms and precise refresh timing |
Reach for a materialized view when you want automatic freshness and transparent substitution, especially for queries issued by tools you do not control. Reach for a scheduled summary table when the transformation is too complex for a view or when you need to control exactly when the refresh runs to manage its cost.
Which views actually pay off?
The economics are a ratio: the saving is bytes scanned avoided across all reads, and the cost is the maintenance to keep the view current as base data changes. A view pays off when reads are frequent and base data changes moderately, because each read banks the saving and maintenance stays low. It does not pay off when base data churns rapidly, because the view is constantly rebuilt, or when the aggregation is queried rarely, because there are too few reads to recover the maintenance. So target the views at the queries that appear repeatedly in your most expensive scans, not at every dashboard.
Find the aggregations that show up again and again in your highest bytes scanned queries. Those repeated, expensive aggregations over moderately changing data are exactly where a materialized view turns a recurring scan into a cheap read. Rarely queried or fast churning data is not.
A worked example
A European SaaS company powered executive dashboards with aggregations that rescanned large event tables every few minutes on BigQuery on demand, driving a large share of the bill. We identified the handful of aggregations responsible for most of the bytes scanned, created materialized views over them so the dashboards read precomputed results, and left rarely run analyses on direct queries. Bytes scanned on the dashboard workload fell sharply, the views stayed cheap to maintain because the base data changed only moderately, and BigQuery spend dropped while dashboards refreshed faster. Figures are verified against billing data and anonymized.
Where this fits
Materialized views are one tactic within the broader compute model decision in on demand versus capacity pricing in BigQuery, and they belong in the regular review described in the GCP data review playbook. 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
What is a BigQuery materialized view?
Do materialized views save money in BigQuery?
Materialized view or summary table in 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.