Denormalization: trading write cost for read speed

WHY IT EXISTS Normalized schemas minimize redundancy and protect consistency, but they push cost onto reads through joins and recomputation. Denormalization deliberately reverses that for workloads where read performance matters more than storage efficiency or write simplicity.

A GOOD ANSWER COVERS What it is: introducing controlled redundancy, such as duplicating a frequently joined column into a child table, storing a precomputed count or total, or maintaining a flattened read model. The motivation is to remove joins, aggregations, or fan-out from the hot read path so queries hit fewer tables and run faster.

A CONCRETE SCENARIO A product page shows each item's average rating and review count on every load. Computing those by aggregating the reviews table per request is expensive at high traffic, so you store avg_rating and review_count on the product row and update them when a review is written. A reporting dashboard similarly uses a pre-aggregated summary table refreshed periodically instead of scanning raw events live.

THE TRADE-OFFS Writes get harder. The duplicated rating must be recalculated and written whenever reviews change, so writes do more work and touch more rows. Consistency becomes a risk: the cached value can drift from the source of truth if an update fails or races, so you need triggers, transactional updates, or async reconciliation, and you accept possible eventual consistency.

LIKELY FOLLOW-UPS How do materialized views fit, how do you keep duplicates in sync, and how do you decide when to denormalize versus add an index or cache.

ONE CONCRETE EXAMPLE An e-commerce order list stores the customer name on each order row so the list renders without joining customers; the price is faster reads, the cost is updating that name everywhere if the customer renames.