Storing derived data in PostgreSQL: generated columns versus materialized views

What it is

The documentation calls a generated column "for columns what a view is for tables": GENERATED ALWAYS AS (expr) with VIRTUAL (computed on read, no storage; the default since PostgreSQL 18) or STORED (computed on insert and update and written to disk). The expression may use only immutable functions, may not reference another generated column, a subquery or another table, and the column cannot be written directly. A materialized view stores the output of an arbitrary query; REFRESH MATERIALIZED VIEW replaces its contents completely, and the view cannot be updated directly.

Why it matters

Both replace recomputation in application code, and both can drift from intent: a stored generated column costs write time and space on every update, a materialized view returns stale rows until its next refresh. Picking the wrong one yields either slow writes or wrong reads.

How to apply

• Per-row normalisation (lower(email), a tsvector built from title and body, a bucketed timestamp): a STORED generated column, indexed like any other column; the value is always current. An expression index is the alternative when no column is needed, but the query must then repeat the expression exactly.
• Per-row values that are cheap and rarely filtered on (unit conversions, a display name concatenated from parts): a virtual generated column, which costs nothing on write.
• Aggregates over many rows (daily totals, rankings, denormalised joins for a dashboard): a materialized view with a unique index on its key, refreshed by a scheduled job with REFRESH MATERIALIZED VIEW CONCURRENTLY. The documentation requires a unique index on column names, without expression or WHERE, for CONCURRENTLY, and notes that a plain refresh can block readers.
• Show the refresh time next to data served from a materialized view, and alert when the refresh job has not run.
• When a summary must be current while the base tables change constantly, maintain a summary table in the same transaction as the write or through triggers; a materialized view refreshed every minute is a full recomputation every minute.

Pitfalls

WITH NO DATA leaves a materialized view in an unscannable state until the first refresh, and CONCURRENTLY cannot be used for that first population; only one refresh at a time may run per view. Virtual generated columns cannot use user-defined types or functions. A generated column cannot be part of a partition key and cannot have a default or identity definition.