Denormalization

In Turkish: Denormalizasyon

Updated September 30, 20262 min read

In short

Denormalization is the deliberate duplication of data across tables or documents so that frequent reads need fewer joins, at the cost of more complex writes.

What is denormalization in databases?

Denormalization means intentionally adding redundant copies of data to a database design that would otherwise be normalized. The goal is to make common reads faster or simpler, usually by avoiding joins or repeated calculations when a page or report is loaded.

Typical examples are storing the customer's name directly on each order row, keeping a comment_count column on a post instead of counting comments every time, building summary tables of daily totals, or embedding author details inside every article document in a document database. Every copy must be kept in sync whenever the original changes, using application code, database triggers, background jobs, or materialized views. If that syncing fails, the copies drift apart, a problem called an update anomaly.

Denormalization is like writing a friend's phone number both in your phone and on a note on the fridge: it is quicker to find, but when the number changes you must remember to update both. It is common in data warehouses, which use star schemas with wide tables, in read-heavy web applications, in NoSQL data modeling, and anywhere reads vastly outnumber writes.

Denormalization is the opposite move to normalization, not a replacement for it. Normalization removes duplication so each fact lives in one place and stays correct, while denormalization adds some duplication back, on purpose, for speed. A table that was never normalized in the first place is simply messy, not denormalized. A good rule of thumb is to normalize first and denormalize only where measurements show a real performance problem.

Key takeaways

Denormalization adds deliberate copies of data to speed up reads.
It reduces joins and repeated calculations on frequent queries.
Every copy must be kept in sync, which makes writes more complex.
It is common in data warehouses, NoSQL designs, and read-heavy apps.
Start from a normalized design and denormalize only where it is measured to help.

Example

Storing a comment count instead of counting every timesql

-- Normalized: count the comments every time a post is shown
SELECT p.id, p.title, COUNT(c.id) AS comment_count
FROM posts AS p LEFT JOIN comments AS c ON c.post_id = p.id
GROUP BY p.id, p.title;

-- Denormalized: keep a copy of the count on the post itself
ALTER TABLE posts ADD COLUMN comment_count INTEGER NOT NULL DEFAULT 0;

-- ...and update the copy in the same transaction as each new comment
BEGIN;
INSERT INTO comments (post_id, body) VALUES (42, 'Nice post!');
UPDATE posts SET comment_count = comment_count + 1 WHERE id = 42;
COMMIT;

Readers ask

Is denormalization bad?

No, it is a legitimate trade-off. It becomes a problem only when the duplicated data is not kept in sync, or when it is added without a measured need.

When should you denormalize a database?

Consider it when a frequent, important read is slow because of joins or aggregates and indexes alone don't fix it. It suits data that is read far more often than it changes.

Is denormalization the same as caching?

They are related but not the same. A cache keeps temporary copies outside the main data store and can be thrown away, while denormalized data lives inside the database design itself and is expected to stay accurate.