Systems & Backend

Denormalization

Deliberately duplicating data across tables to make reads faster, trading write complexity for read speed.

Denormalization is intentionally storing redundant copies of data — the opposite of normalization — so a read can be served without expensive joins. It trades write-time complexity and storage for read-time speed.

Worked example: storing a denormalized author_name on every post row avoids joining to the users table on every feed render; the cost is updating that copy everywhere if the author renames. Gotcha: the duplicated data can drift out of sync, so you need a disciplined way to keep copies consistent (application logic, triggers, or a CDC pipeline) — denormalize for a measured read bottleneck, not by default.