# leveldb-rs: a LevelDB reimplementation for Rust, with an explicit warning > The leveldb-rs project is a from-scratch Rust implementation of Google's LevelDB with no bindings, published on crates.io as rusty-leveldb, and the author states plainly that he does not endorse using it for data you care about. The on-disk format is intended to be identical, which is the whole point and also the risk. **dermesser/leveldb-rs** — A reimplementation of LevelDB in Rust (no bindings). - Repository: https://github.com/dermesser/leveldb-rs - Stars: 578 · Forks: 74 - Language: Rust - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/dermesser-leveldb-rs ## The author's warning comes before anything else in the README The project describes itself as a fully compatible implementation of LevelDB in Rust, and adds in parentheses that any incompatibility is a bug. The implementation is very close to the original, to the point that you can often see the same algorithm translated one to one, with class and struct names and method names similar or the same. Then there is the note that matters most, and it is placed in bold right after that claim. The author does not endorse using this library for any data that you care about. He does care, however, about bug reports. That is a precise and unusual position, and it is worth understanding what it means rather than reading it as boilerplate. The claim of full compatibility is about the file format and the observable behaviour, which is a strong claim to make and also the source of the risk. A format-compatible implementation that has a bug can produce a database that looks right until it does not, and if the original has a behaviour that the port has not matched, the data is still on disk in the original format and equally hard to recover. The author is drawing the line at: use it to learn from, use it to experiment with, tell me when it is wrong. The status section is honest in the same register. It says working fairly well, and asks you to file an issue if you encounter problems. That is the whole status report, and it is worth weighing against a project that publishes a compatibility matrix. ## The goals are about data layout and readability, not about speed The stated goals are four, and none of them is performance. As few copies of data as possible is the first. Most of the time, slices of bytes, &\[u8], are used, and owned memory is represented as Vec and then possibly borrowed as a slice. The caveat given is that zero-copy is not always possible and sometimes simplicity is favoured. Correctness is the second, and the description is telling in how specific it is. It is a self-checking implementation with good test coverage, just like the original implementation. The self-checking part is what makes a compatibility claim testable, since the original has its own test suite and the port can be run against the same expectations. Clarity is the third, described as commented code with clear structure, and the parenthetical hope is that it is doing a better job than the original implementation. That is the claim you would expect from a port that exists partly as a teaching artefact. The fourth goal is the interesting one. It is about coming close-ish to the original implementation, clarifying the translation of typical C++ constructs to Rust, and doing a better job at helping understand the internals. So the project is explicit that it is both an implementation and an explanation, and that the second purpose is where it thinks it adds something over just reading the C++. The readme for a Rust port of a C++ codebase is where the design decisions of the original become visible, because a straight translation preserves the algorithm and the data structures, and the places where the Rust version diverges are the places where the original made a choice that did not translate directly. The same algorithm translated one to one is a feature for a reader trying to understand LevelDB, and it is a constraint that will show up in the code. ## The feature flags decide which runtime you are on The Cargo manifest is where the optional machinery is visible, and the feature names are the API surface in practice. The default feature set is fs, which pulls in errno and fs2. The fs2 dependency at 0.4.3 is what provides file locking, and errno is the error type used by the filesystem layer, so the default build is the synchronous one with filesystem support and nothing else. Async support is opt-in and comes in two flavours. The async feature enables asyncdb-tokio, which in turn enables the tokio dependency at 1.39.3 with the rt and sync features. And asyncdb-async-std enables async-std at 1.12.0. Those two are separate features rather than one async feature, so a project picks its runtime deliberately instead of getting both. The core dependencies are small and each has a clear job. crc32c at 0.6.8 is the checksum LevelDB uses for its data blocks, integer-encoding at 3.0 handles the varint encoding of sequence numbers and lengths, bytes at 1.10.1 is the byte buffer type, rand at 0.8.5 is for the write-ahead log and the random seeds, and snap at 1.0 is the frame compression library. The library target is declared as both cdylib and rlib, so the crate can be used as a Rust dependency or loaded as a shared library, and the include list restricts what is published to src, the Cargo.toml, the LICENSE and the README. The version is 4.0.2, the edition is 2021, the licence is MIT, and the author is Lewin Bormann. ## The examples directory is a test suite in disguise The examples are the most substantial part of the repository, and they are arranged as a workspace with eight members. There is write-a-lot, which is the standard LevelDB benchmark for sequential write throughput, and leveldb-tool, which is the command line utility that ships with LevelDB for inspecting a database. word-analyze is a workload that analyses a word count database. stresstest is the random mixed workload that LevelDB uses to shake out bugs under concurrent readers and writers. mcpe is the missing-person style workload that reads a block and scans it. There is kvserver, which exposes a database over a socket. And there are two async examples, asyncdb-tokio and asyncdb-async-std, one per async runtime the crate supports. Their presence as separate workspace members rather than a single example with a flag is a good sign, because it means both runtimes are exercised by the build rather than only one being claimed to work. The build script is examples/build_examples.sh, and the top level also has a coverage.sh. The presence of a coverage script next to a crate whose stated goal includes good test coverage is consistent with the goals being taken seriously, and the benchmarks are declared in the manifest with a maps_bench entry using the bencher harness. The .hgignore and .hgtags files at the root show that this repository predates or sits alongside a Mercurial history, which is a small marker of the project's age and of the fact that this implementation has been developed over a long period rather than in a burst. ## Conclusion leveldb-rs suits a Rust project that wants LevelDB semantics without a C++ dependency or a bindings layer, and the near one-to-one translation of the original algorithms is what makes it a useful reference as well as an implementation. It does not suit you for data you care about, and that is the author's own stated position rather than my inference. Before you evaluate it, read the status note, which says working fairly well and asks for issue reports, and check the feature flags you need, since the default set is fs while the async support is opt-in and split across a tokio variant and an async-std variant. ## FAQ ### Is the leveldb-rs crate safe to use for important data? The author explicitly says he does not endorse using this library for any data that you care about, while stating that he does care about bug reports. The project claims full format compatibility with the original, and treats any incompatibility as a bug. ### What is the crate name for leveldb-rs? It is published on crates.io as rusty-leveldb, at version 4.0.2, with the repository at github.com/dermesser/leveldb-rs. The Rust edition is 2021 and the licence is MIT. ### Does leveldb-rs support async use? Yes, as opt-in features. The async feature enables asyncdb-tokio, and asyncdb-async-std is a separate feature for the other runtime, so a project chooses one. The default feature set is fs, which brings in errno and fs2 for filesystem support and file locking. ### What examples does leveldb-rs ship with? The examples directory is a workspace with write-a-lot, leveldb-tool, word-analyze, stresstest, mcpe, kvserver, and the two async examples asyncdb-tokio and asyncdb-async-std, plus a build_examples.sh script to build them. ## Sources - [dermesser/leveldb-rs on GitHub](https://github.com/dermesser/leveldb-rs) - [Issues](https://github.com/dermesser/leveldb-rs/issues) - [License: MIT](https://github.com/dermesser/leveldb-rs/blob/master/LICENSE) - [README](https://github.com/dermesser/leveldb-rs/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dermesser-leveldb-rs