No storage engine is perfect. Every design choice that improves one dimension makes another dimension worse. We measure these trade-offs using three Amplification factors, formalized in the RUM Conjecture (2016, Harvard DASlab):
You can optimize for Reads, Updates (Writes), or Memory (Space), but optimizing for any two of these necessarily degrades the third.
This is not a software limitation — it is a fundamental constraint, like the CAP theorem for distributed systems.
The Three Amplifications Defined
1. Read Amplification (RA)
For one logical read (e.g., SELECT * FROM users WHERE id = 1), how many physical disk pages must be read?
- A ratio of 1 means the engine reads exactly the data you asked for — ideal.
- A ratio of 10 means the engine reads 10x more data than necessary to answer your query.
2. Write Amplification (WA)
For one logical write (e.g., updating 10 bytes), how many bytes are actually written to the physical storage device?
- A ratio of 1 means 10 bytes written to disk — ideal.
- A ratio of 400 means 4,000 bytes written to disk for a 10-byte logical change.
- High write amplification directly degrades SSD lifespan (SSDs have a finite number of write cycles per cell) and consumes disk I/O bandwidth.
3. Space Amplification (SA)
How much physical disk space is consumed relative to the logical size of the data?
- A ratio of 1.0 means the data on disk is exactly the size of the raw data — ideal.
- A ratio of 2.0 means you are using twice the disk space of your actual data.
The Conjecture in Practice
| Engine | Read Amp | Write Amp | Space Amp |
|---|---|---|---|
| B-Tree | Low (~1) | High (~10–400x) | Medium (~1.3–1.5x) |
| LSM Tree (untuned) | High (~5–10) | Medium (~10–30x after compaction) | High (~1.5–3x) |
| LSM Tree (tuned with Bloom Filters + aggressive compaction) | Medium (~2–3) | High (~20–50x) | Low (~1.1x) |
Notice that tuning an LSM tree to reduce read amplification (via Bloom Filters) costs space amplification (Bloom Filters consume RAM). Tuning it to reduce space amplification (via aggressive compaction) costs write amplification (more compaction = more bytes rewritten). The RUM Conjecture holds.
A common senior-level interview question is: "You're seeing high disk I/O on your Cassandra cluster even though write traffic is low. What's happening?" The answer is compaction-driven write amplification. Compaction is a background process that rewrites data even when no new writes are coming in. The follow-up is: "How would you reduce it?" — options include choosing a compaction strategy (STCS vs. LCS vs. TWCS), increasing SSTable size thresholds to reduce compaction frequency, or partitioning data by time so old SSTables are never compacted (they're just dropped when they expire).