Deep Dive: Write Amplification

B-Tree Write Amplification

B-Trees store data in fixed-size pages (typically 4 KB or 8 KB). When you update a single field — say, changing a 10-byte email address — the engine must:

1. Read the entire 4 KB page into memory.
2. Modify the 10 bytes.
3. Write the entire 4 KB page back to disk.

Write Amplification = 4,096 bytes written / 10 bytes changed = ~400x

This is before accounting for the WAL write (another sequential write of the change) and potential page splits (which write two new pages plus an updated parent page). In the worst case, a single logical write can trigger a cascade of page splits up the tree, each requiring its own random write.

For SSDs, this matters enormously. A consumer NVMe SSD might be rated for 600 TBW (terabytes written). If your database has a 400x write amplification factor and your application writes 1 GB/day of logical data, the SSD is actually absorbing 400 GB/day of physical writes — exhausting its rated lifespan in under 5 years instead of the expected 1,600+ years.

LSM Tree Write Amplification

The initial write to an LSM Tree is extremely efficient: data goes to the MemTable in RAM, then is flushed as a large sequential write to disk. The initial write amplification is close to 1x.

However, this is deceptive. The same data is rewritten multiple times as it moves through compaction levels:

Write Journey of a Single Record:
  1. Written to MemTable (RAM) — no disk write yet
  2. Flushed to Level 0 SSTable — 1st disk write
  3. Compacted from L0 into L1 — 2nd disk write
  4. Compacted from L1 into L2 — 3rd disk write
  5. Compacted from L2 into L3 — 4th disk write
  ...
  Total: 1 logical write → 10–30 physical disk writes over the record's lifetime

The key distinction is when the amplification occurs. B-Tree write amplification is synchronous — it happens immediately when the client writes, adding latency to every write operation. LSM Tree write amplification is asynchronous — it happens in the background during compaction, so individual write latency is low, but total disk throughput consumed is high.

Practical implication: An LSM-based system can absorb write bursts gracefully (they buffer in the MemTable), but if the write rate consistently exceeds the compaction rate, the number of Level 0 SSTables grows unbounded, eventually causing write stalls as the engine throttles new writes to let compaction catch up.