When can denormalization be a better design choice than normalization?
Interview preparation resource from Gate Smashers.
Denormalization can be a better choice when the system is read-heavy and repeated joins or aggregations are a proven performance bottleneck. It intentionally introduces controlled redundancy to make reads faster and is commonly considered for reporting, dashboards, materialized summaries, analytics, or other workloads where reads greatly outnumber writes, but it requires active consistency management and should be based on actual query measurements and access patterns.
When to consider denormalization
Denormalization is appropriate when a system is read-heavy and repeated joins or aggregations are a proven performance bottleneck. Instead of normalizing strictly for minimal redundancy, you introduce controlled duplication to reduce the amount of runtime work required for queries.
What denormalization does
In a normalized database, information is split into well-structured related tables to improve consistency and reduce duplication, but complex reports may require many joins. Denormalization stores some repeated or precomputed information so a query can read fewer tables or perform less work at runtime, making reads faster at the expense of redundancy.
Common use cases (examples)
Denormalization is commonly considered for workloads where reads greatly outnumber writes and query latency matters. Typical examples include:
- Reporting systems: Precompute or duplicate fields to avoid heavy joins when generating reports.
- Dashboards: Store aggregates or summary fields so dashboard queries return quickly.
- Materialized summaries: Maintain denormalized summary tables to serve aggregated queries.
- Analytics: Duplicate or pre-aggregate analytic dimensions to speed up queries.
- Read-heavy workloads: Any workload measured to be read-dominant where join cost is a bottleneck.
Trade-offs and cautions
The main trade-off is consistency management: if the same fact is stored in multiple places, every copy must remain synchronized. Writes may require updating repeated data, increasing complexity. Therefore, denormalization should be based on actual query measurements and access patterns and not used blindly.