Normalized databases are excellent for correctness. Each fact lives in one place, updates are clean, and constraints are easier to enforce.

But many high-traffic systems eventually hit read paths where normalized data is too expensive to assemble on every request. A page may need data from five tables. A dashboard may aggregate millions of rows. A service may need data owned by another service, but calling that service on every request is too slow or too fragile.

Denormalization is the deliberate duplication of data to make reads faster, simpler, or more independent.

Done deliberately, denormalization is a considered trade-off rather than bad database design. Reads get faster and writes get more complex. Storage usage increases, and data can become stale or inconsistent.

Good denormalization starts with a clear read problem and a plan for keeping duplicated data trustworthy.

In a normalized relational schema, data is split into related tables to reduce duplication.

For a blog application, a clean schema might look like this:

This design is good for writes. If a user changes their name, you update one row in users.

To display a post with comments and comment author names, the database joins the tables:

At small scale, this is perfectly fine. Even at large scale, joins can be fine when tables are indexed well and the result set is bounded.

The problem appears when the read path becomes expensive or operationally awkward, for example when a query joins large tables and runs too often, aggregates too many rows at request time, crosses shards or service boundaries, or shows up on a low-latency page where the normalized version has too much variability. Reads that happen far more often than the underlying data changes are also a strong signal.

Denormalization is one way to move work away from the critical read path.

The normalized design remains the source of truth. The denormalized copy exists because a specific read path needs a faster shape.