Materialized View

The Materialized View pattern precomputes a view of data, shaped for how it will be read, and stores it so queries hit ready-made results instead of computing them on demand. It optimizes for read performance when the source data is not stored in a form convenient for querying.

The problem is expensive reads: aggregations, joins across sources, or transformations that are costly to run repeatedly. Computing them per request strains the data store and slows responses.

How It Works

The application or a background process derives a view from one or more source datasets and persists it. Reads then query the materialized view directly. The view is considered disposable: it can be rebuilt from the sources at any time, so it need not be the system of record.

Keeping the view current is the central concern. It can be refreshed on a schedule, recomputed when sources change, or updated incrementally in response to events. Native materialized views exist in many databases; in distributed and polyglot systems the pattern is implemented with derived tables, search indexes, or read models updated by an event pipeline.

When to Use It

Use it for read-heavy workloads with costly queries: dashboards, reporting, summaries, and combining data from multiple stores into a query-friendly shape. It pairs naturally with CQRS, where read models are materialized views.

Avoid it when source data changes constantly and views cannot be kept acceptably fresh, or when the read cost is already low.

Trade-offs

Materialized views introduce staleness between source changes and view refresh; applications must tolerate eventual consistency for those reads. Maintaining and refreshing views costs storage and compute, and incremental update logic can be complex. A view tuned for one query shape does not serve others, so multiple views may be needed.

The payoff is fast, predictable reads and reduced load on source systems.

Related Patterns

It overlaps with Cache-Aside (a cache is an ephemeral view) and Index Table (a focused index is a kind of view). In Event Sourcing and CQRS, materialized read models are projected from the event log.

Example

A reporting dashboard needs daily revenue by region from millions of order rows. Computing it per request is slow. A scheduled job aggregates orders into a materialized view table keyed by date and region. The dashboard reads this small, pre-aggregated table in milliseconds. Each night the job refreshes the view; an event-driven variant updates the affected day's aggregate as new orders arrive, keeping the view near-current.