DEV Community

Cover image for B-Trees vs. LSM-Trees: Why your Database choice is actually a Trade-off
Tejas
Tejas

Posted on

B-Trees vs. LSM-Trees: Why your Database choice is actually a Trade-off

Introduction
We often treat databases like black boxes. You throw data in, you get data out. But underneath the hood, how that data is physically stored on disk determines if your app scales or crawls. Today, we're looking at the two heavyweights of storage engines: B-Trees and LSM-Trees.

1. B-Trees: The Read Specialist
B-Trees are the backbone of most Relational Databases (RDBMS) like PostgreSQL and MySQL.

  • How it works: Data is stored in fixed-size "pages." When you update a record, the database finds the specific page and overwrites it in place.
  • The Big Win: Because the data is strictly ordered and balanced, looking up a specific key is incredibly fast.
  • The Catch: Writing is "heavy." The DB has to find the exact spot on disk, which leads to random I/O-a major bottleneck for high-velocity data.

2. LSM-Trees: The Write Powerhouse
Log-Structured Merge-Trees (LSM) power the world of NoSQL and Big Data (Cassandra, ScyllaDB, RocksDB).

  • How it works: Instead of finding a spot to "overwrite," an LSM-tree just appends the new data to a log in memory (MemTable). Periodically, these logs are flushed to disk as sorted files (SSTables).
  • The Big Win: Writing is nearly instantaneous because the system just appends data sequentially.
  • The Catch: "Read Penalty." To find a piece of data, the system might have to check multiple files on disk. It uses background "Compaction" to merge these files and keep things clean.

The Comparison Table

Feature B-Trees LSM-Trees
Primary Strength Fast Reads Fast Writes
Storage Style Update-in-place Append-only
I/O Type Random I/O Sequential I/O
Common Use SQL / General Purpose NoSQL / Time-series / Logging

Which one should you choose?

  • Pick B-Trees if your application is "Read-Heavy" (e.g., a standard E-commerce site where users browse products more than they update profiles).
  • Pick LSM-Trees if your application is "Write-Heavy" (e.g., tracking billions of sensor metrics, chat logs, or high-frequency trading data).

Conclusion
System design is the art of choosing which "pain" you can live with. Do you want slower writes for faster reads? Or are you okay with a background cleanup process in exchange for lightning-fast ingestion?

What's your preferred storage engine? Let's discuss in the comments!

Top comments (0)