What is denormalization?

Denormalization is the intentional introduction of redundancy into a database design by combining tables or duplicating data to improve read performance at the cost of storage and update complexity. It is the deliberate reversal of normalization for performance reasons. When to denormalize: when normalized queries require many JOINs that are too slow for the required throughput (read-heavy workloads); when reporting or analytics queries need to aggregate data frequently; when the data is rarely updated (changes to denormalized data must update all copies). Examples: (1) Storing a user's order count in the users table (instead of calculating with COUNT every time); (2) Storing product name in order_items even though products already has it (product name can change, but historical order data should keep the name at time of purchase); (3) Pre-computed summary/reporting tables updated on a schedule. Trade-offs: faster reads (fewer JOINs), slower writes (must update all redundant copies), risk of inconsistency. Denormalization is common in OLAP (analytics) databases, data warehouses, and high-traffic web applications. It should be a deliberate, documented decision made after profiling, not a habit.