An LSM tree keeps writes cheap by flushing them to immutable sorted files (SSTables) and merging those files later in the background. That merge step is compaction, and how you do it is the single most consequential design choice in an LSM engine. “Merges in the background” hides a real cost.
Three amplifications, pick two
Every time compaction merges files it rewrites data — reads the inputs, writes a fresh merged output. So a byte written once can be rewritten to disk many times over its life. That ratio — bytes physically written ÷ bytes the application asked to write — is write amplification. It fights two siblings:
- Read amplification — how many SSTables a single read might have to probe.
- Space amplification — wasted disk from superseded versions, tombstones, and the temporary copies a merge needs.
The governing law (informally, the RUM conjecture): you get to minimize two of {read, write, space} — never all three. Every compaction strategy is just a different choice of which corner to sacrifice.
Size-tiered (STCS) — the write-heavy default
Group SSTables by size; when ~four files of roughly equal size pile up, merge them into one ~4× bigger file. Flushes drop 10 MB files; four → 40 MB; four of those → 160 MB; and so on.
- Write amp: low — a byte is only rewritten when its tier fills, which is rare. This is why it’s the write-heavy favorite.
- Read amp: high — a key can live in a small recent file and as an old version in a big one, so a read may fan out across one file per tier (Bloom filters trim it, but the files still exist).
- Space amp: high — duplicated keys across tiers waste space, and merging a 160 MB tier transiently needs room for inputs and output, so disk usage can nearly double mid-compaction. That spike is STCS’s classic operational headache.
Leveled (LCS) — the read-heavy default
Impose a rule: within any one level, SSTables have non-overlapping key ranges. So a key appears at most once per level, and a read checks at most one file per level — worst case ≈ the number of levels (~5–7), not the number of files. Reads and space both win.
But keeping ranges non-overlapping is not cheap — and this is the part most people get backwards. To push a small file down into a level, its range straddles several existing files there; you must read all of them, merge, and rewrite fresh non-overlapping files. Since each level holds ~10× the data of the one above, a small newcomer forces you to rewrite a slice of a level an order of magnitude bigger — and it happens again at every level the data passes through. A single key gets physically rewritten 10–40 times over its life. That’s high write amplification — the corner leveled compaction pays.
The whole topic in one shape
| Strategy | Write amp | Read amp | Space amp | Use when |
|---|---|---|---|---|
| Size-tiered | low | high | high (transient ~2×) | write-heavy, ingest-bound |
| Leveled | high (10–40×) | low (≤1 file/level) | low | read-heavy or space-constrained |
Two strategies, opposite corners of the same triangle. You can’t escape the triangle — you only choose which amplification you can afford. It’s the same shape as the B-tree vs LSM choice one level up: every storage engine is a variation on “which amplification can I afford to pay?”