Materialized view 2026-11-05
A materialized view stores the result of a defining database query, allowing later queries to read the stored result. An ordinary database view retains the definition and evaluates it against the relevant underlying data when queried. A materialized view trades storage and maintenance work for potentially cheaper repeated reads; its freshness depends on when and how the result is maintained.[ref]
Materialized Views in the PostgreSQL documentation. §39.3, opening comparison of CREATE MATERIALIZED VIEW and CREATE TABLE AS, persisted results and refresh
Suppose an orders table contains totals 10 and 20 for one customer. A materialized view defined by
SELECT customer_id, SUM(total) AS total FROM orders GROUP BY customer_id stores 30 for that customer. Inserting a third order worth 7 changes the underlying sum to 37. In PostgreSQL, the previously stored 30 remains until a refresh replaces the result, for example with REFRESH MATERIALIZED VIEW customer_totals;. The stored answer can therefore be internally consistent yet out of date.A dashboard that tolerates nightly updates can benefit from this arrangement, especially when the defining database query combines many rows. An application requiring the latest committed totals needs a suitable maintenance policy and database transaction semantics. The term materialized view alone does not promise automatic updates or an always faster query.[ref]
Materialized Views in the PostgreSQL documentation. §39.3, sales_summary example and nightly REFRESH MATERIALIZED VIEW