Member-only story
How I Design Database Schemas That Scale — Normalisation, Denormalisation, and When to Break the Rules
Normalise until it hurts, denormalise until it works. A code-heavy, opinionated field guide to schema design — the decisions that determine whether your database is an asset or a liability three years from now.
The Only Schema Philosophy That Has Never Let Me Down
Normalise until it hurts, then denormalise until it works.
The schema you design in an afternoon will either quietly carry your product for a decade or generate data-corruption bugs you’re still chasing at 2 am three years from now. There’s no middle ground, and the difference comes down to a handful of decisions most teams make on autopilot. That’s the whole thing: start clean and correct, prove where it’s actually slow with real data, and denormalise surgically where the numbers justify it. Everything below is the detail behind that sentence. I’ve watched teams skip the first half (“we’ll need speed”) and drown in data-integrity bugs, and I’ve watched teams cling to textbook third normal form while a report times out. The craft is knowing which half you’re in right now.
