facebook/rocksdb

RocksDB is a mature embedded storage engine, not a database server: adopting it means writing code against its C++ interface and owning the operational details of compaction and tuning. It earns its place when you need multi-terabyte local persistence on flash and can afford to design around LSM trade-offs.

The problem

An application needs to store a large, mutable key-value dataset locally — more than fits comfortably in RAM, with a mix of reads and writes — and restart without losing it. Wiring that together by hand means managing files, indexes, write-ahead logging, crash recovery and space reclamation. RocksDB moves that work into a library: the caller opens a database, reads and writes keys, and the engine handles persistence and background compaction. The result is a persistent store inside the process rather than a separate server to operate.

What's different

RocksDB descends from LevelDB (upstream LevelDB) and keeps the LSM design: writes go to memory tables and are flushed to sorted files, with background compaction merging them. The project frames its design around explicit trade-offs between write amplification, read amplification and space amplification, plus multi-threaded compaction for databases holding multiple terabytes in one instance (README). That framing is the practical difference: you are choosing a point on a read/write/space curve rather than accepting fixed behavior.

The trade-off is that the knobs are yours. Compaction style, write buffers, filters and memory limits need to match the workload, and the consequences show up under sustained write load rather than in a quick test. The public API in include/ is small, but the README warns that any other internal header may change without notice (project instructions), so integration should stay behind the documented interface. An examples directory and wiki are the intended starting points; the wiki also documents features not in LevelDB, which is useful if you are migrating. A 2022 HN commenter reported converting a large database program from threads to coroutines and roughly doubling performance in heavy-I/O, high-concurrency cases (comment); a reply questioned how the benchmark was core-limited (reply), so treat that as a single unverified report rather than a promise.

Who should try it

The good fit is a systems team building a database, index, message store or metadata layer that needs embedded persistence at large scale and is comfortable tuning an LSM engine. A 2016 HN commenter mentioned CockroachDB as heavy user, and another noted TiKV storing consensus state in RocksDB (discussion), which illustrates the kind of infrastructure role it plays. The poor fit is an application that just needs a small local store or a ready-made key-value server: RocksDB is a library with no server binary in the README, so you would still need to build the service, protocol and operational tooling around it. Teams that want a SQL database or a managed service are also outside the target.

Requirements and limitations

Expect a C++ integration and a build from source; the README points to examples and external discussion channels rather than a packaged installer (project instructions). Because the engine runs in your process, its memory and compaction threads compete with your application, so you must size write buffers and background work deliberately. Persistence needs care around options changes and version upgrades; there is no README guidance on migration here, so verify compatibility with the wiki before committing to an on-disk format you depend on.

Licensing is dual GPLv2 or Apache 2.0, and you may choose either (README). For many commercial users the Apache option matters, but confirm it fits your distribution and legal requirements. Ongoing work is tuning and monitoring compaction behavior as data volume and write rates grow, not one-time setup.

HotRepo's take

This is a 5080-day-old project with 32,232 stars as of a single 2026-10-28 daily-board observation (+6 that day); the recorded history is insufficient to judge trend persistence. Hacker News discussion exists (2016 thread), but counts only show volume, not consensus. Before adopting, read the wiki's options and compaction documentation and run a write-heavy benchmark against your own data shape, since the read/write/space trade-off is the thing RocksDB asks you to own.