RocksDB — Facebook's Embeddable Persistent Key-Value Store

What it is

RocksDB is a C++ embeddable persistent key-value store developed at Meta (Facebook). It uses an LSM-tree (Log-Structured Merge-tree) architecture optimized for fast storage devices like NVMe SSDs. RocksDB powers the storage layers of CockroachDB, TiKV, Kafka Streams, and MyRocks (MySQL with RocksDB backend).

RocksDB is for database engineers and systems developers who need an embedded storage engine with high write throughput, tunable read performance, and efficient compression.

The project is actively maintained with regular releases and a growing user community. Documentation covers common use cases, and the open-source nature means you can inspect the source code, contribute fixes, and adapt the tool to your specific requirements.

How it saves time or tokens

Building a production-quality storage engine from scratch takes years. RocksDB provides a battle-tested foundation with configurable compaction strategies, bloom filters, compression (LZ4, Zstd, Snappy), column families, and transaction support. Teams embed RocksDB instead of reinventing the storage layer.

How to use

1. Install RocksDB from source or via package manager.
2. Open a database instance with configured options (block cache, compaction style, compression).
3. Use Put, Get, Delete, and Iterator operations for key-value access.

Example

#include <rocksdb/db.h>
#include <rocksdb/options.h>

int main() {
  rocksdb::DB* db;
  rocksdb::Options options;
  options.create_if_missing = true;
  options.compression = rocksdb::kLZ4Compression;

  rocksdb::Status s = rocksdb::DB::Open(options, "/tmp/testdb", &db);
  assert(s.ok());

  // Write
  db->Put(rocksdb::WriteOptions(), "key1", "value1");

  // Read
  std::string value;
  db->Get(rocksdb::ReadOptions(), "key1", &value);
  // value == "value1"

  delete db;
  return 0;
}

Related on TokRepo

• AI Tools for Database -- Database engines and storage tools
• AI Tools for DevOps -- Infrastructure and data platform tooling

Common pitfalls

• Default compaction settings are tuned for general workloads. Write-heavy workloads benefit from Level compaction, while space-sensitive workloads should use Universal compaction.
• RocksDB block cache size must be tuned to available memory. Setting it too small causes excessive disk reads; setting it too large starves the OS page cache.
• Write amplification is inherent to LSM-trees. Monitor compaction stats and tune max_bytes_for_level_base and level0_file_num_compaction_trigger to balance write amplification against read performance.

Before adopting this tool, evaluate whether it fits your team's existing workflow. Read the official documentation thoroughly, and start with a small proof-of-concept rather than a full migration. Community forums, GitHub issues, and Stack Overflow are valuable resources when you encounter edge cases not covered in the documentation.