RocksDB Overview

RocksDB is an embeddable key-value store built on a log-structured merge tree. It is a library, not a server: you link it into your process and call it directly.

It is most commonly encountered as the storage engine inside something else — MyRocks in MariaDB and MySQL, the DocDB layer of YugabyteDB, Kafka Streams state stores, and many others. Understanding its behaviour therefore explains the behaviour of systems built on it.

The LSM model

1. Writes go to a memtable in memory and to a write-ahead log.
2. When the memtable fills, it is flushed to an immutable SSTable at level 0.
3. Compaction merges SSTables into higher levels, discarding overwritten and deleted keys.

The consequences follow directly:

• Writes are fast and sequential. No in-place updates, no random writes.
• Reads may touch several levels. Bloom filters and block caches keep this bounded.
• Deletes write tombstones, removed only when compaction reaches them — the same dynamic as Cassandra tombstones.
• Compaction is continuous background work that competes with foreground traffic for I/O and CPU.

What it gives you

• Ordered key-value storage with prefix iteration.
• Atomic write batches.
• Snapshots and consistent iterators.
• Column families — independent keyspaces sharing one WAL.
• Transactions, in the optimistic and pessimistic variants.
• Extensive tuning surface for the read/write/space amplification trade-off.

What it does not

Column families

// Independent keyspaces, each with its own options, sharing one write-ahead log.
std::vector<ColumnFamilyDescriptor> cfs = {
  {kDefaultColumnFamilyName, ColumnFamilyOptions()},
  {"index", index_options},
  {"metadata", metadata_options}
};

Column families let you tune differently for different data — a small, hot metadata space and a large, cold data space — while keeping writes atomic across them.

The amplification trade-off

Every LSM configuration trades three quantities against each other:

You cannot minimise all three. Level compaction favours read and space amplification; universal compaction favours write amplification and costs space. See Write Amplification.

Operational characteristics

• Compaction backlog is the health metric. If compaction falls behind, level 0 accumulates files, reads slow down and eventually writes stall.
• Memory is the block cache plus memtables. Sizing both is the main capacity decision.
• The WAL must be fsynced for durability, and disabling that trades data for speed exactly as elsewhere.

When RocksDB is embedded in another system, that system usually exposes a subset of these knobs — and the underlying behaviour is what you are actually tuning.