The Price of Concurrency
Think of a busy library where books can never be erased — only crossed out and rewritten on a new page. Over time, the library fills up with crossed-out pages that nobody reads anymore. Finding a live page means wading through all the dead ones. This is exactly what happens inside a database that uses MVCC (Multiversion Concurrency Control).
MVCC is the mechanism that allows multiple users to read and write a database simultaneously without stepping on each other's toes. When you UPDATE a row, the database does not overwrite the original. Instead, it writes a brand-new version of the row and marks the old version as "dead." When you DELETE a row, the database does not erase it — it stamps it with a "dead" marker called a tombstone. The old data stays on disk until something comes along to clean it up.
This design is intentional and powerful: readers never block writers, and writers never block readers. But it creates a debt. Every write operation leaves behind a dead row. In a high-throughput system processing thousands of writes per second, that debt accumulates fast. The dead rows are called bloat in PostgreSQL and shadows in Cassandra. Bloat has two concrete consequences: it wastes disk space (you might have 1 TB of physical files for a 100 GB logical dataset), and it slows down queries (the database must scan past dead rows to find live ones). Vacuum (PostgreSQL) and Compaction (Cassandra, ScyllaDB) are the background processes responsible for paying down this debt. If they fall behind, your database degrades and eventually fails.