Write Amplification¶

What is it: Write amplification occurs when one logical write results in multiple physical writes.

graph LR w["1 logical INSERT"] --> heap["heap page write"] w --> i1["index 1 write"] w --> i2["index 2 write"] w --> i3["index 3 write"] w --> i4["index 4 write"] w --> i5["index 5 write"]

Where it appears: B+Tree indexes: inserting one row updates the heap page plus every index on that table. A table with 5 indexes incurs 6 physical writes per logical row insert.

LSM trees (Cassandra, LevelDB, RocksDB): writes go to a memtable, flushed to L0 SSTables, then compacted through L1, L2, ... levels. A single write may be rewritten multiple times during compaction. Write amplification factor of 10–30× is common.

Copy-on-Write B+Trees (BTRFS, LMDB): on update, copy the modified page and all ancestor pages up to the root — a single key update writes O(height) pages.

Why it matters: high write amplification reduces SSD lifespan (SSDs have limited write cycles per cell) and saturates disk I/O bandwidth on write-heavy workloads.

Mitigation: batch small writes into larger sequential writes (WAL, LSM memtable), use fewer indexes (each index is extra write amplification), tune compaction settings in LSM-based stores.

Common pitfall¶

Adding indexes freely because "reads need to be fast" without weighing the write side is how write amplification quietly creeps up on a write-heavy table — every additional index is another mandatory write on every insert/update/delete, regardless of whether that index is ever actually used for a read. See Index Types for when an index's write cost outweighs its read benefit — this is the write-amplification cost showing up as a concrete decision, not just an abstract concern.