{"post":{"slug":"lsm-tree-vs-b-tree-2026","title":"LSM Trees vs B-Trees: Why Your Database Chose One","excerpt":"Two ways to organise data on disk, optimised for opposite workloads. Which one your database uses explains most of its performance character.","category":"code","date":"August 11, 2026","author":"ByteLedger Team","content":"<span class=\"dropcap\">T</span>wo 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.\n\nThe difference is usually not tuning. It is which data structure organises data on disk, and there are essentially two answers in wide use.\n\n## What changed in 2026\n\n- **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.\n- **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.\n- **Compaction tuning matured.** Better default strategies and adaptive compaction reduced the operational burden that made LSM engines demanding.\n- **Write amplification entered SSD sizing.** Teams started accounting for how much a storage engine actually writes when specifying drive endurance.\n\n## The core difference\n\n**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.\n\n**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.\n\nEverything else follows from that.\n\n| | B-tree | LSM tree |\n| --- | --- | --- |\n| Write path | Random page updates | Sequential appends |\n| Write throughput | Moderate | High |\n| Read path | Root to leaf, predictable | May check several levels |\n| Read latency | Consistent | Variable |\n| Space usage | Some page fragmentation | Old versions until compacted |\n| Background work | Modest | Compaction, continuous |\n| Deletes | Remove from page | Write a tombstone marker |\n| Best for | Read-heavy, mixed workloads | Write-heavy ingestion |\n\n## Write amplification cuts both ways\n\nBoth structures write more bytes than your application hands them, and the reason differs.\n\n**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](/blog/write-ahead-logging-explained-2026), the change is written twice: once to the log, once to the page.\n\n**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.\n\nThis 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.\n\n## Compaction is the operational cost\n\nThe defining LSM operational characteristic: a continuous background process merging files, consuming I/O and CPU while your queries want the same resources.\n\nWhen 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.\n\nThe 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.\n\nB-trees have their own background cost — page splits and, under MVCC, cleanup of dead versions — but it is generally less dominant. See [MVCC explained](/blog/mvcc-explained-2026) and [index bloat](/blog/index-bloat-explained-2026) for the B-tree side.\n\n## Common mistakes\n\n- **Choosing an engine on benchmarks alone.** Benchmark workloads rarely match yours, and operational maturity matters more.\n- **Ignoring compaction in capacity planning.** It needs headroom in I/O and CPU, not just storage.\n- **Expecting deletes to free space immediately on LSM.** Tombstones first, reclamation later.\n- **Not measuring p99.** Compaction spikes are invisible in median latency.\n- **Undersizing SSD endurance.** Write amplification means the drive writes far more than your application does.\n- **Assuming faster storage removes the difference.** It narrows the write gap; the structural distinction remains.\n\n## FAQ\n\n**Which do common databases use?**\nTraditional 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.\n\n**Does this affect indexes too?**\nYes — 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.\n\n**Which handles range scans better?**\nBoth 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.\n\n**Should I switch engines to fix a performance problem?**\nRarely the right first move. Query design, indexing, and schema usually offer larger gains for far less risk — start with [query planners](/blog/query-planner-explained-2026) and [database indexing](/blog/database-indexing-explained-2026). Engine choice matters most when specifying a new system.\n\n## Where to go next\n\nFor the B-tree structure in more depth, read [what is a B-tree database](/blog/what-is-a-b-tree-database-2026). For the durability mechanism both rely on, [write-ahead logging](/blog/write-ahead-logging-explained-2026), and for the version churn that drives B-tree background work, [MVCC explained](/blog/mvcc-explained-2026).","hue":300,"metaTitle":"LSM Trees vs B-Trees: Why Databases Differ","metaDescription":"How LSM trees and B-trees differ in write and read performance, why compaction causes latency spikes, and which workloads suit each storage engine.","keywords":["lsm tree vs b-tree","log structured merge tree","database storage engine","write amplification","compaction database","read amplification","storage engine performance","database internals 2026"],"tldr":["**B-trees update in place, LSM trees append and merge later** — that single difference produces every other distinction between them.","**LSM trees win on write throughput** — sequential appends beat random page updates by a wide margin on any storage.","**B-trees win on predictable read latency** — an LSM read may check several levels before finding the value.","**Compaction is the LSM tax** — background merging consumes I/O and causes periodic latency spikes.","**Skip:** choosing a database on this alone. Operational maturity and ecosystem matter more than the storage engine for most teams."],"readTime":"4 min read","wordCount":973},"related":[{"slug":"data-lake-vs-data-warehouse-2026","title":"Data Lake vs Data Warehouse in 2026: How to Choose","excerpt":"A data lake stores raw files cheaply; a data warehouse stores structured, query-ready tables. Here is an honest 2026 comparison and a clear rule for picking the right one.","category":"code","date":"July 31, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":302},{"slug":"toast-storage-explained-2026","title":"TOAST Storage: Where Large Values Actually Live","excerpt":"A row containing a large text or JSON value does not store it inline. It goes to separate storage, which explains why SELECT * can be dramatically slower than selecting columns.","category":"code","date":"February 9, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":309},{"slug":"database-isolation-levels-2026","title":"Database Isolation Levels: The Bugs You Only Get Under Load","excerpt":"Your code is correct when one user runs it. Two users at once produce a result neither would accept. Isolation levels decide which of those anomalies you get.","category":"code","date":"August 12, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":304}],"sameCategory":[{"slug":"bazel-build-explained-2026","title":"Bazel Explained: What Hermetic Builds Actually Cost","excerpt":"Bazel delivers reproducible, precisely cached builds and demands that you describe everything. Here is what you get, what it costs, and who should say no.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":145},{"slug":"graphql-federation-2026","title":"GraphQL Federation: One Graph, Many Teams","excerpt":"Federation composes independently-owned subgraphs into a single API. Here is what it solves, the operational cost it adds, and when a simpler gateway is enough.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":300},{"slug":"hermetic-builds-explained-2026","title":"Hermetic Builds Explained: Same Inputs, Same Output","excerpt":"A hermetic build depends only on declared inputs. Here is what that property gives you, the common leaks that break it, and how to move toward it incrementally.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":130},{"slug":"monorepo-tooling-compared-2026","title":"Monorepo Tooling Compared: What You Actually Need","excerpt":"Monorepo tools solve task orchestration and caching, not repository layout. Here is what each tier provides and how to tell when you have outgrown the simple option.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":150}],"newer":{"slug":"least-privilege-iam-2026","title":"Least Privilege IAM: Narrowing Permissions Safely","excerpt":"Broad permissions get granted to unblock someone and never get narrowed. Here is a practical method for reducing them using observed usage rather than guesswork.","category":"code","date":"August 11, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":6},"older":{"slug":"matter-smart-home-standard-explained-2026","title":"Matter Smart Home Standard: What It Actually Fixes","excerpt":"Matter was pitched as the fix for smart home fragmentation. Here is what problem it actually solves, what it does not, and how to tell if a device labeled Matter compatible will genuinely work the way you expect.","category":"tech","date":"August 11, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":248}}