Lsm-Trees

Implementing LSM Trees in RocksDB: Storage Layout, Compaction, and Latency Trade-offs

LSM trees power high-performance key-value stores like RocksDB. This post breaks down their storage layout, compaction mechanics, and the latency trade-offs that matter for production workloads.

Stylized illustration of a bloom filter grid and an LSM-tree SSTable stack.

Implementing Bloom Filters in LSM-Tree Storage Engines for High-Throughput Key Lookups

Bloom filters are the unsung hero of LSM-tree reads: a few bits per key let engines like RocksDB skip 99% of disk seeks. Here’s the math, the tradeoffs, and what to tune in production.

Abstract diagram of an LSM-tree with sorted runs cascading across levels.

Architecting RocksDB Storage Engines: Selecting Between Tiered and Leveled Compaction for Production Workloads

Compaction strategy is the single most consequential knob in a RocksDB deployment. This post walks through how tiered (universal) and leveled compaction actually work, what they cost at write and read time, and how to pick one based on your workload shape.

Illustration comparing B‑Tree nodes and LSM Tree levels.

Memory Management Tradeoffs: B‑Trees vs. LSM Trees

A deep dive into the memory management trade‑offs between B‑Trees and LSM Trees, with practical guidance for database developers.

Illustration of a Log‑Structured Merge tree versus a B‑tree.

Why LSM Trees Outperform B-Trees for Write Heavy Workloads

LSM trees excel in write‑heavy scenarios by batching writes and deferring compaction, while B‑trees suffer from random I/O. This post breaks down the mechanisms that give LSM trees their edge.