Heavy write throughput

Most write-heavy systems are built on a log-structured merge tree (LSM tree). A write goes to an append-only log and an in-memory table, which is later flushed to disk as an immutable sorted file; background compaction merges those files. Nothing is read or rewritten in place on the write path. A B-tree, used by most classic relational engines, updates pages in place, so a stream of random inserts turns into random page reads and writes. The LSM tree pays later instead: compaction rewrites the same data several times. That cost is called write amplification, the bytes written to disk divided by the bytes the application wrote, and it trades off against read amplification (how many files a lookup touches) and space amplification (how much extra disk the files take).

Spreading writes over many machines matters as much as the engine. Data is split by a partition key, and each partition lives on a few nodes, so a key that takes most of the traffic (one popular device, today’s date, a counter) makes one partition hot while the rest sit idle. DynamoDB, for example, caps each partition at 1,000 write units per second. Leaderless designs, where any replica can accept a write, avoid funnelling every write through one leader per shard.

To judge a claim, look for a benchmark that runs for hours, not minutes, so compaction has caught up, and that reports p99 latency for reads during the write load, not only peak inserts per second. Check the disk bytes written per byte stored, what happens when compaction falls behind (stalls or throttling), and whether the key distribution was uniform or skewed. YCSB’s workload A (half reads, half updates) is a common starting point.