Read Amplification

Amplification measures the gap between the logical operation and the physical work it causes. Every storage engine picks a point in a three-way trade, and no configuration minimises all three.

Read amplification is what you feel as query latency: a read that must consult ten files instead of one is ten times the work. It is highest in LSM engines when compaction falls behind, and in B-tree engines when a table is bloated.

Write Amplification

One logical write becomes many physical bytes:

• Write-ahead log — the change is written to the log.
• Data pages — the page is written, and a page is typically 8–16 KB regardless of how many bytes changed.
• Index pages — every index on the table is updated.
• Doublewrite or full-page writes — protection against torn pages costs an extra copy.
• Compaction or vacuum — the same data is rewritten again later.

A factor of 5–20× is normal. It matters for three reasons: it consumes IOPS, it consumes SSD endurance, and it consumes replication bandwidth.

Reducing it:

• Fewer indexes. Each one multiplies the write cost.
• Narrower rows and updates. Updating one column of a wide row still writes the page; splitting rarely-changed wide columns into a separate table reduces the page churn.
• Append instead of update where the model allows.
• Batch writes, so one page write covers many logical changes.
• Compression, which trades CPU for fewer bytes written.

Space amplification

Disk holds more than the live data: dead tuples awaiting vacuum in PostgreSQL, undo history in InnoDB, obsolete SSTable entries awaiting compaction in LSM engines, deleted-but-not-merged documents in Lucene segments.

The trade in practice

LSM engines (RocksDB, Cassandra, ScyllaDB, ClickHouse) favour write amplification: writes are sequential appends, and the cost is paid later by compaction as read and space amplification. Compaction strategy is the dial. See Compaction Strategies and RocksDB Performance.

B-tree engines (PostgreSQL, InnoDB) favour read amplification: a read is a small number of page accesses, and the cost is paid at write time by page updates and, in MVCC systems, by vacuum.

Neither is better. They suit different workloads, which is why a write-heavy workload on a B-tree engine and a read-heavy point-lookup workload on an LSM engine both feel like fighting the database.

Measuring it

• PostgreSQL — WAL bytes generated per transaction (pg_stat_wal), and table versus index size growth over time.
• MySQL — Innodb_pages_written against the logical write rate.
• Cassandra / ScyllaDB — SSTables per read (nodetool tablehistograms), and compaction throughput against the write rate.
• RocksDB — the compaction statistics in rocksdb.stats, which report amplification directly.