B-Tree vs LSM-Tree: How Your Database's Storage Engine Shapes Performance

Every database makes a foundational choice between two storage structures — B-trees and LSM-trees — that determines how it handles reads versus writes under load. B-trees update data in place, keeping records fully sorted for fast lookups, making them the default for read-heavy systems like PostgreSQL and MySQL. LSM-trees instead buffer writes in memory and flush them sequentially to disk, which makes them far more efficient for high-volume write workloads used by systems like Cassandra and RocksDB. However, LSM-trees introduce read overhead and a background compaction process that competes for disk I/O, which can spiral into serious latency issues under sustained write pressure. Engineers rarely make this choice consciously, but mismatching a workload — such as running high-ingest time-series data on a B-tree-backed database — can mean fighting the storage engine rather than solving the actual problem.