{
  "id": 7599416,
  "title": "B-Tree vs LSM-Tree: the storage-engine tradeoff behind every database you use",
  "url": "https://urgent.news/2026/09/15/b-tree-vs-lsm-tree-the-storage-engine-tradeoff-behind-every-database",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-15T17:32:22.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/darshan_turakhia/b-tree-vs-lsm-tree-the-storage-engine-tradeoff-behind-every-database-you-use-3l3l"
  },
  "original_language": "en",
  "account": "Relational databases make a key decision at the storage-engine level before any query is written: whether reads or writes matter more. This choice manifests as a decision between two data structures: B-tree or LSM-tree. Most engineers are unaware of this choice, as it simply determines how the database performs under load.\n\nA B-tree updates data in place. It locates the exact leaf page where a key belongs and updates it directly, keeping the tree fully sorted at all times. Reading from a B-tree involves traversing a single path from the root to the leaf, with no ambiguity about a key's location because there is only one copy. In contrast, an LSM-tree (log-structured merge-tree) does not modify old data during a write. Instead, it buffers writes in memory, writes them to new immutable files on disk, and merges those files together later in the background. Writes are sequential appends, not random rewrites, which is why LSM-trees excel in high ingest volumes, such as Cassandra, RocksDB, LevelDB, and HBase.\n\nThe tradeoff between the two is evident. B-trees incur costs during writes. Once the dataset exceeds memory capacity, a page update that used to be a quick in-memory write becomes a disk seek. Under heavy write loads, the tree also spends resources rebalancing and splitting pages as they fill, ensuring every leaf remains at the same depth. LSM-trees, on the other hand, incur costs during reads. A single key can exist simultaneously in the in-memory memtable, the most recently flushed file, and several older files. The most recent write is considered the winner, but a lookup must check each location to find a match. While Bloom filters can mitigate this by skipping most files without opening them, a worst-case LSM-tree lookup still requires checking more places than a B-tree ever does.\n\nAnother hidden cost of LSM-trees is the maintenance process called compaction. This background operation merges small files into larger ones and eliminates superseded key versions. However, compaction is not free maintenance. It competes for the same disk I/O and CPU resources needed for live traffic. A compaction backlog, where writes outpace merging, can lead to increased read latency as lookups check more uncompacted files, causing the system to spiral if incoming write traffic is not throttled to allow compaction to catch up. This scenario is a common failure mode in LSM-tree-based systems, and it can be particularly evident in high-write environments like Cassandra.\n\nThe choice between B-trees and LSM-trees is typically made once, implicitly, by the database chosen by a team years ago. Most engineers only think about this decision when a write-heavy workload starts struggling on a B-tree-backed system that was not designed for such loads. A prime example is trying to use Postgres for time-series data, event logging, or any scenario where data is ingested more frequently than it is read back. The resulting struggles often stem from pitting the storage engine against the actual problem rather than addressing the root issue. Some engines attempt to hedge their bets by providing storage engines that can switch between B-tree and LSM-tree implementations, such as MySQL's MyRocks storage engine, which swaps InnoDB's B-tree for an LSM-tree to cater to write-intensive workloads.",
  "summary": "Every relational database you've ever used made a bet at the storage-engine level, before you wrote a single query: reads matter more than writes, or writes matter more than reads. That bet shows up as a choice between two data structures, a B-tree or an LSM-tree. Most engineers never think about it. It's still deciding how their database behaves under load. The actual tradeoff A B-tree updates…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}