Glossary

Materialized view

A query result stored physically and refreshed on a schedule or trigger, rather than recomputed on every read.

A materialized view is the saved, physical output of a query — unlike a standard database view, which is just a stored query re-executed on every read, a materialized view computes its result once and stores it, so subsequent reads return the cached rows instead of rerunning the underlying joins and aggregations.

Materialized views are refreshed either on a fixed schedule, on demand, or incrementally as the underlying tables change, depending on what the database or warehouse supports; a full refresh recomputes everything, while an incremental refresh — closer to what an incremental model does in a transformation tool — updates only the rows affected by new or changed source data. The trade-off is staleness: a materialized view is only as current as its last refresh.

They are used to speed up expensive, frequently repeated queries — a daily revenue rollup queried by dozens of dashboards, for instance — without rewriting the source tables, and are a standard query optimization tool in both transactional databases and OLAP warehouses. The common pitfall is forgetting a materialized view exists and continuing to query the raw base tables, or relying on its data without knowing how stale it is allowed to get.

Last reviewed September 22, 2026

In the index now

Related terms

Incremental model A transformation that updates only new or changed rows on each run instead of rebuilding the entire table. Query optimization The process, largely automated by the database, of choosing the fastest execution plan for a given query. Data warehouse A centralized, structured database optimized for fast historical reporting rather than day-to-day transactions. OLAP (online analytical processing) A category of technology optimized for fast, multi-dimensional aggregation and slicing of data for analysis. dbt (data build tool) An open-source tool from dbt Labs that lets analytics teams write data transformations as version-controlled, tested SQL. Denormalization Deliberately introducing redundancy into a data model to reduce joins and speed up read queries.

Related guides

How to build a metrics layer Define each metric once, in code, so every tool that queries revenue or churn gets the same number — and govern changes to it. How to choose a real-time OLAP database Real-time OLAP databases trade operational complexity for speed on fresh data — the decisions are architecture, query concurrency, and who runs it. How to reduce data warehouse costs Where usage-based warehouse spend actually goes, and the levers — query, storage, scheduling — that reliably bring it down.