Trading Joins for Copies
Normalized schemas store each fact once and reconstruct views with joins. Denormalization deliberately duplicates data, such as storing a precomputed count or an embedded copy of a field, so a hot read avoids an expensive join or aggregate. The read gets faster and simpler.
What You Pay
- Every write must update all copies, or they drift out of sync.
- Consistency becomes an application responsibility rather than a single source of truth.
- Storage grows, and the duplicated data can itself bloat caches.
When It Is Worth It
Denormalize when reads vastly outnumber writes, the join is provably the bottleneck, and the duplicated field changes rarely. A precomputed counter on a frequently read profile is a classic win. A frequently changing value copied to many places is a trap.
Keeping Copies Honest
- Update copies in the same transaction as the source so they cannot diverge.
- Or accept eventual consistency and rebuild the derived data on a schedule.
- Add a reconciliation job that detects and repairs drift.
Key idea
Denormalization speeds reads by duplicating data, but every write must keep all copies in sync, so it pays off only when reads dominate and the copied field is stable.