rust-rocksdb: a RocksDB binding that compiles the C++ library into your binary and makes you pick features to control that build

Clang and LLVM are the only listed requirement, and they are needed because bindgen runs at build time

The README's requirements section has one line: Clang and LLVM. That is a build dependency, not a runtime one. The crate generates its C bindings with bindgen, and the default feature bindgen-runtime makes bindgen link dynamically to libclang. A machine without libclang cannot compile the default configuration.

The crate manifest adds a Rust floor. Cargo.toml sets rust-version to 1.88.0 and edition 2021, and the repository carries a rust-toolchain.toml. The package is named rocksdb and described as a Rust wrapper for Facebook's RocksDB embeddable database, with the keywords database, embedded, LSM-tree and persistence.

The workspace has one member besides the root: librocksdb-sys, which holds the compiled C++ code. The root crate depends on librocksdb-sys version 0.19.0 with its static feature on, which is why the README says the binding is statically linked with a specific version of RocksDB.

Building from a clone needs git submodules for RocksDB and each compression library

The binding is statically linked with a specific version of RocksDB, and that source comes in through git submodules. If you build from a checkout instead of from crates.io, you have to fetch them:

git submodule update --init --recursive

The repository has a .gitmodules file, which is where those submodules are declared.

A dependency from crates.io avoids this step, since the published crate is the route the README badges point to, with docs on docs.rs. The practical meaning of a statically linked library is that the RocksDB version you get is fixed by the crate version you pick. You do not choose RocksDB independently, and upgrading RocksDB means taking a new crate release.

The repository also holds CHANGELOG.md and MAINTAINERSHIP.md, which describe changes and how the project is maintained.

Five compression libraries are on by default and one Cargo.toml edit narrows that

By default the crate enables Snappy, LZ4, Zstd, Zlib and Bzip2 through features. Each of them compiles a C or C++ library into your build, so a project that needs only one pays for five in build time and binary size. The README does not give figures for either.

To keep only LZ4, switch off the defaults and name the feature:

[dependencies.rocksdb]
default-features = false
features = ["lz4"]

There is a trap in this edit. The default feature list in Cargo.toml also includes bindgen-runtime. With default-features set to false, bindgen-runtime goes too, and you must add a bindgen feature yourself or the build has no bindgen link mode. The README's Alpine example shows the full pattern, with the bindgen feature listed beside the compression features.

Other features in the manifest are jemalloc, io-uring, valgrind, rtti, serde1 and raw-ptr, and the README does not describe them.

Concurrent column family creation is off unless you enable multi-threaded-cf

RocksDB allows column families to be created and dropped from multiple threads at the same time. This crate does not allow it by default, which the README attributes to compatibility. If you need that behaviour, enable the crate feature multi-threaded-cf, which makes the binding's data structures use RwLock by default.

There is a second route. You can create DBWithThreadMode<MultiThreaded> directly, without turning on the feature.

The effect is a locking trade. The default configuration avoids lock overhead on its internal structures but forbids creating or dropping column families through shared access from several threads. A service that creates a column family per tenant at runtime, from worker threads, needs one of the two routes. The README does not say what the compile error or runtime failure looks like if you try it without them, so test that path early.

On Alpine the bindgen-static feature replaces the dynamic libclang link

Two features control how bindgen reaches libclang. bindgen-runtime links dynamically to libclang, suits most platforms and is on by default. bindgen-static links statically and suits musl-based platforms such as Alpine Linux. The README says the two are mutually exclusive and will not compile if both are enabled.

The Alpine recipe turns the defaults off and lists everything wanted:

[dependencies.rocksdb]
default-features = false
features = ["bindgen-static", "snappy", "lz4", "zstd", "zlib", "bzip2"]

Because default-features is false, the compression features must be named again, as shown.

On Windows, a separate feature, mt_static, asks for the library to be built with the /MT flag, which uses the static run-time library. The README says this helps when different run-time versions conflict in the dependency tree.

The lto feature demands clang as CC and matching LLVM versions on both sides

Link-time optimization is off by default. The lto feature compiles RocksDB with the -flto flag. The README attaches an important note: you must use clang as CC, for example CC=/usr/bin/clang CXX=/usr/bin/clang++, and the LLVM version of that clang must be the same as the one used by the Rust compiler.

On the Rust side the README prescribes the flags RUSTFLAGS="-Clinker-plugin-lto -Clinker=clang -Clink-arg=-fuse-ld=lld". That also makes lld a requirement.

So enabling lto turns a plain cargo build into a toolchain matching exercise. If your distribution ships a clang whose LLVM version differs from the one inside your rustc, the build fails or the optimization does not apply, and the README only links the Rust documentation on linker plugin LTO for more information. Treat lto as a feature for release pipelines you control, not for developer laptops with mixed toolchains.

Releases arrive about once a year, and the maintainer asks for issues to prioritize features

Three releases are listed: v0.25.0 on 2026-08-16, v0.24.0 on 2025-08-10 and v0.23.0 on 2024-12-24. The last push was the same day as v0.25.0. The gaps are about eight months and one year, so expect a slow cadence, and the repository is not archived.

The contributing section is informal. Feedback and pull requests are welcome, and if a particular RocksDB feature matters to you, the maintainer asks you to open an issue and says it will be prioritized. The README does not list which RocksDB features the binding lacks.

Cargo.toml names two authors, Tyler Neely and David Greenberg, and the license is Apache-2.0. There is a Gitter lobby for chat. The README documents no async API.

Editorial conclusion

Use the rocksdb crate if you want an embedded LSM-tree key-value store in a Rust program and can supply Clang and LLVM at build time. Skip it if you cannot compile C++ in your build environment or need an async API, because the README documents neither a prebuilt library nor async. Before adopting it, decide which compression features you need and set default-features accordingly, since the defaults pull in five compression libraries.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. rust-rocksdb/rust-rocksdb on GitHub