Compare the storage path
A B-tree maintains ordered keys in a balanced structure. An LSM design buffers writes and merges sorted data over time. PostgreSQL's B-tree documentation and the RocksDB overview describe two concrete implementations. A product's behavior includes far more than its tree family.
For an illustrative workload, imagine repeatedly updating recent keys while also scanning a historical range. Ask how much data each write changes, how many structures a read must consult and how maintenance competes for disk bandwidth.
Three amplification budgets
| Budget | Question to measure |
|---|---|
| Write amplification | How much physical work follows one logical write? |
| Read amplification | How many structures or pages are consulted? |
| Space amplification | How much space do retained versions and maintenance need? |
An LSM system can transform many small writes into larger sequential operations, while compaction creates additional work. Bloom filters and indexing reduce unnecessary reads but use memory and depend on configuration. B-tree behavior depends on page layout, cache state, splits and concurrency. Neither name predicts your p95 latency.
A write-heavy ledger also needs range reads
Consider a device telemetry service that continually writes new readings and lets users inspect a time range for one device. The workload contains both sustained writes and ordered reads. A B-tree keeps keys in an ordered search structure; an LSM design organizes writes through memory and sorted files with background merging. Those are storage strategies, not complete database products. Transaction guarantees, replication, query planners and operational limits still depend on the implementation.
For this workload, describe the key distribution, update frequency, range length and retention policy. A monotonically increasing key behaves differently from random updates across a large working set. A range query covering a few minutes behaves differently from one covering years. The choice should be evaluated with those patterns and the device's memory and storage constraints. Avoid asserting that one tree is always faster from a single insertion benchmark. A system can perform well while background work is light and become unpredictable once its sustained workload consumes the available I/O budget.
Compare amplification and latency together
Write amplification describes how much physical work is performed for a logical update. Read amplification describes how much data or how many structures may need examination for an answer. Space amplification describes storage overhead beyond live logical data. These terms make a comparison more useful, but their values depend on engine settings, workload and data distribution. They should be measured with the same durability and compression assumptions on both sides.
An LSM implementation may trade efficient foreground write ingestion for compaction work and additional read paths. A B-tree implementation may offer predictable ordered access while paying for page changes and maintenance. Caching can alter observed latency in both designs. Include sustained behavior, tail latency and disk growth in a comparison rather than looking only at short-run throughput. Specify whether the test includes updates and deletes, and whether it allows background work to finish. A result measured before compaction debt accumulates cannot explain the cost of operating the system continuously with the same arrival rate.
An example comparison fixture
Generate a fixed key distribution and record its random seed. Run insert-only, update-heavy, point-read and range-scan phases separately. Keep durability, compression, cache budget, dataset size and hardware documented. A comparison with one system fully cached and the other reading from disk answers a cache question, not a tree question.
Include a sustained phase long enough to observe maintenance. A short ingestion burst can hide a later compaction backlog. Track write stalls, background bandwidth, space growth and tail latency. Report the state after the workload, not just peak ingest rate.
Transactions and indexes still matter
If your application needs relational constraints, secondary indexes and multi-row transactions, evaluate those capabilities independently. Comparing a bare key-value engine with a relational database can conflate storage mechanics with higher-level features.
Plan disk headroom for maintenance and recovery. A storage engine approaching full disk can behave very differently from a small benchmark with abundant free space. Include a restart and recovery exercise with disposable data.
Choose from the measured pressure
For a read-heavy relational application, existing B-tree indexes may satisfy the workload with less operational complexity. A write-heavy key-value service may benefit from an LSM engine after tuning and measurement. These are engineering hypotheses, not published benchmark results.
Continue with database selection and bottleneck diagnosis to connect storage choices to the actual application.
Investigate storage pressure without changing everything
When latency rises, correlate it with storage utilization, cache effectiveness and maintenance activity. In an LSM engine, inspect compaction backlog and the relevant per-level or file statistics. In a B-tree-based database, inspect query plans, index size and maintenance state using that product's tools. The abstract data structure does not identify a production incident by itself; the engine's observable behavior must connect the symptom to the hypothesis.
Make one bounded change and preserve the workload definition so that the comparison remains interpretable. Changing compression, memory allocation, concurrency and durability simultaneously can create an impressive number with no clear explanation. Include a recovery exercise such as restart and replay, because operational behavior matters alongside the steady-state benchmark. Track disk headroom for background work and document the emergency action that preserves data when capacity is tight. A practical choice states the important query and mutation patterns, the expected maintenance budget and the evidence that would trigger reevaluation, rather than turning B-tree or LSM into a permanent architectural identity. Keep these decision notes with the workload definition for future capacity reviews.
