Normalized Schema With Joins at Read Time Versus Denormalized Profile Document
TradeoffDatabase InternalsJuniorMidUpdated
User-profile service joins users, preferences, and subscription rows on almost every read. Writes are infrequent.
Short answer: Denormalized profile document. Read-heavy, write-light workloads pay the denormalization cost (extra storage, update fan-out) only on rare writes, and amortize it across many cheap single-row reads.
The Two Options
A
Normalized schema with joins at read time
B
Denormalized profile document
Drill This: Your Pick First
The Better Pick
Option B
Denormalized profile document
Read-heavy, write-light workloads pay the denormalization cost (extra storage, update fan-out) only on rare writes, and amortize it across many cheap single-row reads. Joins disappear from the hot path.
When the Other One Wins
Normalized schema with joins at read time
Write-heavy systems with many places to update on a single change (think e-commerce inventory) usually keep normalization to avoid update anomalies and write amplification.