Discofork
Repository brief

facebook/rocksdb

Read the upstream summary on the left, browse the cached forks below it, and load each fork comparison into the right-hand panel.

Cached analysis
cached 2026-03-30T19:59:57.717Z
1mo ago

facebook/rocksdb

facebook/rocksdb is a mature, actively maintained embedded persistent key-value store library for fast storage, with strong adoption signals: 31,671 stars and 6,770 forks. It is centered on an LSM design and is positioned for flash/RAM storage and multi-terabyte databases.

GitHub
Loading tags...
Stars31,671
Forks6,770
Default branchmain
Last pushed2026-03-30T19:01:43Z
Recommended shortcuts

Jump straight into Discofork's strongest cached fork picks, or open a compare view in one click.

Forks

Choose a fork to inspect

10 of 10 fork briefs
Selected

Choose this fork if you want RocksDB adapted for AWS/cloud operations and are willing to trade upstream freshness and general-purpose breadth for deployment-specific behavior. Avoid it if you need the broadest upstream compatibility or want minimal maintenance burden.

Choose this fork if you need TiKV-oriented RocksDB behavior and can tolerate a large upstream gap. Choose upstream if you want the broadest feature set, fastest access to recent fixes, and lower long-term merge risk.

Prefer this fork only if you specifically need its legacy customizations and are willing to own a large rebase burden. For most adopters, upstream RocksDB is the safer choice because this fork is materially outdated and highly divergent.

Choose this fork only if SPDK integration is the requirement; for most adopters, upstream RocksDB is the safer default because this fork is heavily diverged and stale.

Choose this fork only if its NVM/SSD backend work is the reason you need it. For most adopters, upstream RocksDB is the safer default because this fork is materially stale, heavily divergent, and likely missing years of fixes and developer-facing improvements.

Choose this fork only if rDSN-based replication is the product goal. For most adopters, upstream RocksDB is the better base because this fork is very stale, highly divergent, and likely missing many years of upstream fixes and features.

Prefer upstream unless you specifically need the fork's local patches and are prepared to own long-term maintenance. This fork looks too stale and too divergent for most adopters.

Choose this fork only if you need the Ceph-specific patch set and are willing to own a long-lived divergence from upstream. If you want current RocksDB features, fixes, and APIs, upstream is the better default.

Choose this fork only if rDSN-based replication is the goal and you can absorb a stale, highly divergent codebase. For most adopters, upstream RocksDB is the safer choice because this fork is materially outdated and specialized.

Choose this fork only if its backup/restore and read-only DB behavior matches a real requirement you cannot get from upstream. For most adopters, upstream RocksDB is the safer default because this fork is materially behind and appears stale.