What do denormalization and materialized views each do to reduce read load on a database, and what is the recurring cost both approaches share?

## The shared problem Both denormalization and materialized views exist to solve the same underlying problem: some reads are expensive because the data they need is spread across multiple normalized tables or requires heavy computation (joins, aggregations, sorting) to assemble, and doing that work on every single read wastes CPU and I/O on work that's often producing the same or similar answer repeatedly. Both techniques trade write-time or storage cost for read-time speed, but they do it at different granularities and with different mechanics. ## The baseline they push back against **Normalization** - the baseline both techniques push back against - organizes data to avoid duplication: a proper third-normal-form schema stores a fact exactly once and references it by foreign key elsewhere, which keeps data consistent (update it in one place, every reference sees the update) but means assembling a full picture often requires joining several tables together. ## Denormalization **Denormalization** deliberately reintroduces duplication to avoid some of those joins on hot read paths. A common example: - an e-commerce `order_line` table might normally store only a `product_id`, requiring a join to the `products` table to display the product name on an order history page; - a denormalized version stores `product_name` directly on the `order_line` row at the time of purchase. This is not only faster to read (no join), it's also often semantically correct in a way pure normalization isn't - the order should show the product name as it was when purchased, not the current name if the product was later renamed. The cost shows up on the **write side**: any process that creates or corrects that data now has to know about (and update) every duplicated copy, and it's easy for copies to drift if an update path is missed, which is a real production bug class - a customer's display name changes, and half the system reflects the new name while other tables still show the old one, because a denormalized copy was never touched by the update code path. ## Materialized views **Materialized views** operate at a coarser, more automated level: rather than a developer manually deciding to duplicate a specific column, a materialized view is defined by a query - often a join across several tables plus an aggregation, like 'total sales per product per day' - and the database (or a scheduled job) executes that query once and physically stores the result set as if it were a table. Subsequent reads of that data hit the stored, pre-computed rows directly instead of re-running the expensive join-and-aggregate query every time. This is especially valuable for reporting/analytics/dashboard queries that touch large amounts of data and would be far too slow to compute live on every page load, but are read far more often than the underlying data changes. PostgreSQL supports materialized views natively (`CREATE MATERIALIZED VIEW ... AS SELECT ...`, refreshed via `REFRESH MATERIALIZED VIEW`); many analytics/data-warehouse systems build on the same idea more elaborately. ## Refresh, and the freshness-versus-speed decision The refresh mechanism is where the shared risk concentrates: a materialized view's stored result is only as fresh as its last refresh, and refreshes cost real work - re-running the underlying query - so they're typically scheduled (every few minutes, hourly, nightly) rather than continuous. Between refreshes, the view can show numbers that don't match the live source tables, which is fine for a sales dashboard that's acceptable at 15-minutes-stale, and very much not fine for, say, a real-time inventory count used to decide whether to accept an order. Standard (non-materialized) views don't have this problem - they're just a saved query definition, re-executed live every time, always consistent but with none of the performance benefit - so choosing between a plain view and a materialized view is explicitly a freshness-versus-speed decision. ## The shared failure mode The failure mode both techniques share in production is **staleness surfacing where it wasn't expected**: a denormalized copy that a forgotten update path left behind, or a materialized view refreshed on a schedule that a downstream consumer assumed was live. The mitigation pattern is also shared: be explicit about which reads can tolerate staleness (and how much) versus which must go to the source of truth, and invest proportionally in keeping duplicated/materialized data fresh - - via database **triggers**, - **change-data-capture (CDC)** pipelines that propagate updates to denormalized copies, - or simply documenting and monitoring refresh cadence so nobody is surprised. A concrete combined usage: an analytics dashboard uses a materialized view refreshed every 10 minutes for 'orders per hour' charts (acceptable staleness, huge read-cost savings versus live aggregation), while the same system denormalizes a customer's shipping address onto each order row at checkout time (so historical orders show the address used at purchase, not whatever the customer's address happens to be today - correctness, not just performance, motivates that duplication).