Two databases with similar feature sets behave completely differently under load. One handles a write-heavy ingestion workload comfortably and has unpredictable read latency. The other has rock-steady reads and struggles when writes spike.
The difference is usually not tuning. It is which data structure organises data on disk, and there are essentially two answers in wide use.
What changed in 2026
- Storage engines became a selectable option. More databases offer a choice of engine rather than baking one in, which makes understanding the trade practical rather than academic.
- Fast NVMe narrowed the write gap. Random writes got much cheaper than they were on spinning disks, which reduced — without eliminating — the LSM write advantage.
- Compaction tuning matured. Better default strategies and adaptive compaction reduced the operational burden that made LSM engines demanding.
- Write amplification entered SSD sizing. Teams started accounting for how much a storage engine actually writes when specifying drive endurance.
The core difference
A B-tree keeps data in sorted pages and updates in place. Changing a value means finding its page, modifying it, and writing that page back. Reads follow the tree from root to leaf — a small, predictable number of page reads.
An LSM tree never updates in place. Writes go to an in-memory buffer, which is flushed to disk as an immutable sorted file when full. Those files accumulate, and a background process merges them into fewer, larger files. A read may have to check the buffer and several files before finding the current value.
Everything else follows from that.
|
B-tree |
LSM tree |
| Write path |
Random page updates |
Sequential appends |
| Write throughput |
Moderate |
High |
| Read path |
Root to leaf, predictable |
May check several levels |
| Read latency |
Consistent |
Variable |
| Space usage |
Some page fragmentation |
Old versions until compacted |
| Background work |
Modest |
Compaction, continuous |
| Deletes |
Remove from page |
Write a tombstone marker |
| Best for |
Read-heavy, mixed workloads |
Write-heavy ingestion |
Write amplification cuts both ways
Both structures write more bytes than your application hands them, and the reason differs.
A B-tree writes a whole page even when you changed a few bytes. Update one row and a full page — several kilobytes — goes to disk. If your database also uses write-ahead logging, the change is written twice: once to the log, once to the page.
An LSM tree writes the record once on the way in, cheaply. Then compaction rewrites it repeatedly as it merges through levels. A record may be rewritten many times over its life, and total bytes written can exceed a B-tree's for the same data — just spread out and sequential rather than concentrated and random.
This matters for SSD endurance at sustained write volumes. Sequential writes are gentler on flash than random ones, which favours LSM, but the total volume from compaction is real and worth measuring against a drive's endurance rating.
Compaction is the operational cost
The defining LSM operational characteristic: a continuous background process merging files, consuming I/O and CPU while your queries want the same resources.
When it keeps up, everything is fine. When it falls behind — usually because write volume exceeded what compaction can absorb — files accumulate, reads must check more of them, and read latency climbs. The system degrades gradually rather than failing, which makes it easy to miss until it is bad.
The practical consequences: LSM engines have periodic latency spikes correlating with compaction activity, which shows up in p99 rather than median latency. Deletes are not immediate — a delete writes a tombstone, and space is reclaimed only when compaction processes it, so deleting a lot of data can temporarily increase disk usage. And compaction strategy is a real tuning dimension, trading write amplification against read amplification and space.
B-trees have their own background cost — page splits and, under MVCC, cleanup of dead versions — but it is generally less dominant. See MVCC explained and index bloat for the B-tree side.
Common mistakes
- Choosing an engine on benchmarks alone. Benchmark workloads rarely match yours, and operational maturity matters more.
- Ignoring compaction in capacity planning. It needs headroom in I/O and CPU, not just storage.
- Expecting deletes to free space immediately on LSM. Tombstones first, reclamation later.
- Not measuring p99. Compaction spikes are invisible in median latency.
- Undersizing SSD endurance. Write amplification means the drive writes far more than your application does.
- Assuming faster storage removes the difference. It narrows the write gap; the structural distinction remains.
FAQ
Which do common databases use?
Traditional relational databases predominantly use B-trees; many newer distributed and key-value stores use LSM trees. Several databases now let you pick per table, which is worth checking before assuming.
Does this affect indexes too?
Yes — indexes are stored with the same structure as the data in most engines. An LSM engine's indexes have the same write-friendly, read-variable character.
Which handles range scans better?
Both keep data sorted, so both do range scans well. B-trees are typically more consistent because an LSM scan may need to merge across levels.
Should I switch engines to fix a performance problem?
Rarely the right first move. Query design, indexing, and schema usually offer larger gains for far less risk — start with query planners and database indexing. Engine choice matters most when specifying a new system.
Where to go next
For the B-tree structure in more depth, read what is a B-tree database. For the durability mechanism both rely on, write-ahead logging, and for the version churn that drives B-tree background work, MVCC explained.