What Is Write Amplification? SSDs and Databases

Write amplification is the ratio between the amount of data a storage system physically writes and the amount of data the application actually asked it to write. A ratio of 1.0 would mean every logical write costs exactly one physical write; in practice it’s almost always higher, because of how flash storage and log-structured databases actually place data on disk. A write amplification factor of 5 means five bytes hit physical storage for every byte the application wrote.

Where it comes from in SSDs

Flash memory can’t overwrite data in place the way a spinning disk can. It’s organized into pages (the smallest unit you can write) grouped into blocks (the smallest unit you can erase), and a page must be erased before it can be rewritten — but erasure only happens at the block level, and a block holds many pages. If a block contains a mix of valid and stale pages, the SSD’s controller has to copy the still-valid pages elsewhere before it can erase and reuse the block. That copy is a physical write the application never asked for.

This process — garbage collection — is unavoidable in flash storage, but its overhead depends heavily on how full the drive is and how the workload writes. A nearly full drive with lots of small, scattered updates forces more frequent garbage collection and higher write amplification than a drive with headroom and large sequential writes. This is also why SSD manufacturers reserve a chunk of raw capacity as “over-provisioning” invisible to the user — more free blocks give the garbage collector room to work efficiently and directly lowers write amplification.

Write amplification matters for SSDs specifically because flash cells wear out: each cell tolerates a finite number of erase cycles before it can no longer reliably hold a charge. Higher write amplification means the drive burns through its erase-cycle budget faster for the same amount of application-level writing, shortening its usable lifespan.

Where it comes from in databases

The same phenomenon shows up at the database layer, independent of the underlying storage medium, in any log-structured merge-tree based system — RocksDB, Cassandra, and similar engines. An LSM-tree buffers writes in memory and flushes them as immutable sorted files. Over time, background compaction merges these files together, rewriting data that was already durably written once, purely to keep read performance and storage layout efficient. A single logical update to one key can be physically rewritten several times across successive compaction passes before it settles into the tree’s lower levels.

This is a deliberate trade-off, not a flaw: LSM-trees accept higher write amplification in exchange for fast, append-only writes and good compression, which is why they’re common in write-heavy workloads. Systems built on B-trees trade this differently — updates modify pages in place, avoiding compaction-driven rewrites, but in-place updates on flash storage still trigger the SSD-level write amplification described above, and B-trees can suffer more page-level fragmentation under random writes.

Measuring and reducing it

Write amplification factor (WAF) is typically reported as physical bytes written divided by logical bytes written, measured over a representative workload window rather than instantaneously — a single flush can spike the ratio misleadingly. Common levers to reduce it:

• Increase over-provisioning on SSDs, giving the garbage collector more free space to work with.
• Batch and sequentialize writes where possible — random small writes amplify more than large sequential ones, on both flash and LSM-based databases.
• Tune compaction strategy in LSM databases — leveled compaction generally has higher write amplification but better read performance and space efficiency than size-tiered compaction, which writes less but reads more files per query.
• Use TRIM/discard so the SSD controller knows which pages are actually free rather than treating deleted data as still valid until overwritten.

Why it matters beyond disk lifespan

Write amplification isn’t only a durability concern. Every extra physical write consumes I/O bandwidth that a real application write or read could have used instead, so high write amplification directly reduces throughput and increases tail latency under load — the garbage collector or compaction process is competing with your actual queries for the same disk. On cloud storage tiers billed by I/O operations rather than raw capacity, it’s also a direct cost multiplier: five physical writes for one logical write means five times the billed I/O.

The takeaway

Write amplification is the gap between what you asked storage to write and what it actually wrote, and it shows up wherever data can’t be updated cleanly in place — flash’s erase-before-write constraint and LSM-trees’ compaction both produce it for related reasons. It’s not something application code usually controls directly, but understanding it explains why write-heavy workloads benefit from sequential access patterns, why SSDs need free space to perform well, and why database engines trade read, write, and space efficiency against each other rather than optimizing all three at once.