Materialized Views

Many slow database queries do the same expensive work again and again.

A dashboard may join orders, customers, and products, then group the result by region. A reporting page may scan millions of rows to compute daily revenue. A product listing may repeatedly calculate review counts and average ratings.

If the result does not need to be perfectly live, it is wasteful to recompute it on every request.

A materialized view stores the result of a query so future reads can fetch precomputed data. It is a database-supported form of denormalization: keep the source tables normalized for writes, but maintain a read-optimized copy for common queries.

The trade-off is simple. Reads become much faster, but storage usage grows, the stored result can become stale, and refreshing the view costs CPU, I/O, locks, and operational care.

A materialized view is a stored query result with a refresh strategy attached. Treat it as data you have to keep current, not as a cache that takes care of itself.