Chapter 21: Storage Engines — InnoDB, RocksDB, WiredTiger
The storage engine is the component that actually reads/writes data to disk. Different engines make different trade-offs.
B-Tree Based Engines (Read-Optimized)
InnoDB (MySQL default)
- Clustered index (rows stored in PK order)
- MVCC with undo logs
- Row-level locking
- Crash recovery via redo log
PostgreSQL's Heap + Indexes
- Heap storage (rows in insertion order)
- Separate B-tree indexes
- MVCC with multiple row versions in heap
- VACUUM needed to reclaim dead rows
LSM-Tree Based Engines (Write-Optimized)
RocksDB (Facebook), LevelDB (Google)
Write path (LSM-Tree):
1. Write to in-memory buffer (MemTable) — fast!
2. When MemTable full → flush to disk as sorted SSTable file
3. Background compaction merges SSTables
Read path:
1. Check MemTable (RAM)
2. Check each SSTable level (disk) — use bloom filters to skip
3. Merge results
Trade-off: Writes are FAST (sequential). Reads may check multiple files.
| Aspect | B-Tree (InnoDB/PG) | LSM-Tree (RocksDB) |
|---|---|---|
| Write speed | Moderate (random I/O) | Fast (sequential I/O) |
| Read speed | Fast (one lookup) | Moderate (check multiple levels) |
| Space amplification | Low | Higher (multiple copies during compaction) |
| Best for | Read-heavy OLTP | Write-heavy workloads |
WiredTiger (MongoDB default)
Hybrid: B-tree structure with LSM-like write buffering. Supports both document and key-value access patterns.
Choosing a Storage Engine
💡 Rule of Thumb
- General OLTP (reads + writes balanced): B-tree (PostgreSQL, InnoDB)
- Write-heavy (logs, time-series, IoT): LSM-tree (RocksDB, Cassandra)
- Embedded key-value: RocksDB or LevelDB
Key Takeaways
- B-tree engines: good reads, moderate writes (PostgreSQL, InnoDB)
- LSM-tree engines: excellent writes, moderate reads (RocksDB, Cassandra)
- Storage engine choice affects performance characteristics fundamentally
- Most developers don't choose — they pick a database and get its engine