Write Amplification
The ratio between what your application asked to write and what actually landed on physical storage.
Overview
Write Amplification is the ratio between the amount of data actually written to physical storage and the amount of data the application originally asked to write — a ratio that's always at least 1, and one that both WAL-based durability and LSM Tree compaction, covered in the last two chapters, directly contribute to.
Why It Exists
Every layer between 'the application calls UPDATE' and 'bytes land on the physical storage medium' can add its own overhead: the WAL logs the change once, the actual data page write applies it again, an SSD's flash translation layer might rewrite an entire erase block just to change a few bytes, and LSM compaction rewrites the same logical data multiple times while merging SSTables. Naming this ratio explicitly matters because it directly affects both performance — extra I/O the disk has to do — and SSD hardware lifespan, since flash cells wear out after a bounded number of erase cycles.
Real World Example
An application issues a single 100-byte UPDATE. The database writes that 100 bytes to the WAL. It then writes the full 8KB data page containing that row. If it's an LSM engine, that same logical change gets rewritten again during a later compaction pass. And the SSD underneath, physically unable to erase less than a full block at a time, might rewrite a much larger chunk of flash just to update that one page. The 100 bytes the application 'wrote' can easily correspond to tens of kilobytes of actual physical writes.
Example Data
One 100-byte logical UPDATE, layer by layer
| Layer | Bytes Actually Written | Why |
|---|---|---|
| Application's logical write | 100 bytes | the actual data that changed |
| WAL | ~100–200 bytes | the change logged before being applied |
| Data page write | 8,192 bytes | the whole page containing the row is rewritten |
| SSD flash translation layer | up to ~256KB | can't erase less than a full flash block |
Where the Multiplier Actually Comes From
The Formula
Write Amplification Factor = Total Bytes Physically Written ÷ Bytes the Application Requested. A WAF of 1 would mean zero overhead, which essentially never happens in practice.
The Database Layer: WAL + Page Writes, or Compaction
A WAL-based engine writes the change once to the log and again to the actual data page. An LSM Tree engine adds another multiplier on top: every background compaction pass rewrites the same logical data again as it merges SSTables.
The SSD Layer: Flash Translation Layer and Erase Blocks
Flash memory can only be erased in large blocks (often hundreds of KB), even when the actual update is a few bytes. The SSD's internal flash translation layer has to rewrite the whole containing block, adding its own amplification on top of whatever the database layer already added.
Why It Matters: Performance and SSD Lifespan
Every extra physical byte written is extra I/O the disk has to perform, competing with other reads and writes. On an SSD specifically, every physical write also consumes one of a finite number of erase cycles per flash cell — high write amplification measurably shortens the drive's usable lifespan.
Diagram
One logical write, multiplied at every layer on the way to physical storage
Application writes 100 bytes
WAL write
~100–200 bytes
Data page write
8KB — the whole page
LSM compaction (if applicable)
rewrites the same data again later
SSD flash translation layer
up to a full erase block, far larger still
Common Mistakes
Only counting the database's own write amplification and ignoring the SSD's
Why: Total write amplification is the product of every layer's individual amplification — optimizing only the database layer can still leave a large, hidden multiplier at the SSD layer.
Fix: Measure actual physical writes (e.g. via the SSD's SMART data) when diagnosing unexpectedly high I/O or unexpectedly fast drive wear, not just the database's own logical write count.
Treating all write amplification as pure waste to eliminate
Why: Some amplification — specifically WAL logging — is the direct cost of durability. Eliminating it would mean giving up crash safety, not gaining a free optimization.
Fix: Distinguish amplification that buys a real guarantee (WAL durability) from amplification that's genuinely avoidable waste (excessive compaction, poor SSD block alignment).
Choosing between a B+ Tree and an LSM Tree engine based on reputation rather than measured amplification
Why: LSM Trees are often chosen specifically to reduce write amplification for high-write workloads compared to a B+ Tree's page splits, but compaction itself reintroduces its own amplification — the real number depends heavily on the specific workload, not the engine family's general reputation.
Fix: Benchmark actual write amplification for your real workload rather than assuming one engine family is universally better.
Interview Questions
Define write amplification in one sentence.
The ratio between the amount of data physically written to storage and the amount of data the application actually asked to write — always at least 1.
Name two distinct layers that each add their own multiplier to total write amplification.
The database layer — writing a change to both the WAL and the actual data page (and, for LSM engines, rewriting it again during compaction) — and the SSD layer, where the flash translation layer has to rewrite an entire erase block to change even a few bytes.
An SSD-backed database is wearing out flash storage faster than expected. How would you investigate whether write amplification is the cause, and at which layer?
I'd first compare the database's logical write volume (from application/query metrics) against the actual physical bytes written, using the SSD's own SMART/wear-leveling data — a large gap points at write amplification specifically. Then I'd narrow down which layer: check the database's own WAL and compaction volume against its logical writes to isolate the database-layer multiplier, and separately check whether the SSD's block size and the database's page size are poorly aligned, which would point at the storage-layer multiplier instead.
Production Best Practices
Do
✓Measure actual physical write volume, not just logical application writes, when diagnosing I/O or SSD wear issues.
✓Distinguish necessary amplification (WAL durability) from avoidable amplification (poor compaction tuning, misaligned block sizes).
✓Benchmark real write amplification for your actual workload before choosing a storage engine based on reputation.
Don't
✗Don't measure write amplification at only one layer (database or SSD) and assume that's the whole picture.
✗Don't try to eliminate WAL-related write amplification — it's the cost of durability, not waste.
✗Don't assume an LSM Tree engine automatically has lower total write amplification than a B+ Tree without measuring compaction's contribution.
Comparison
| Typical Write Amplification Factor | |
|---|---|
| B+ Tree (in-place, minimal splits) | Low-to-moderate |
| LSM Tree, before compaction catches up | Low |
| LSM Tree, steady-state with compaction | Moderate-to-high |
| SSD flash translation layer alone | Adds its own multiplier on top of the above |