leveldb: an embedded store that stops at one process

An embedded store you call from the same process

LevelDB is a library, not a service. It is described as an ordered mapping from string keys to string values, written at Google by Sanjay Ghemawat and Jeff Dean, and the surface is three calls: `Put(key,value)`, `Get(key)` and `Delete(key)`. Around those sit the pieces that decide how it behaves in your application. Keys and values are arbitrary byte arrays, the store keeps them sorted by key, and a caller can supply its own comparison function to override that sort order. Several changes can be committed in one atomic batch, a caller can take a transient snapshot for a consistent view, and iteration runs forward and backward over the data. Compression is automatic through Snappy, with Zstd also supported, so the codec is not something you pick per write. One more mechanism matters if you test: external activity such as file system operations is relayed through a virtual interface so users can customize the operating system interactions. The README does not enumerate the implementations behind that interface, so a reader who wants to substitute a fake file system has to find the seam in the headers.

No SQL, no indexes, and one process per database

The project states three limits outright, and each one decides whether the library fits your workload. It is not a SQL database. There is no relational data model, no support for SQL queries, and no support for indexes, so anything that reaches for a join or a secondary index is hand written on top of the sorted key iteration the library does give you. Only a single process, possibly multi-threaded, can access a particular database at a time, which means two processes opening the same directory is not a supported configuration and the multi-writer case has to be solved outside the library. And there is no client-server support built in: an application that needs such support will have to wrap its own server around the library. Weigh that third point early, because the wrapper is yours to write, secure and keep alive. The boundary is narrow but clear. This is a component for one address space, and the moment your deployment has a second writer or a network hop, you are building the missing half yourself.

The recurse-submodules flag in the clone line is not decoration

The source is fetched with one command, and the flag in it matters:

git clone --recurse-submodules https://github.com/google/leveldb.git

The tree holds a `.gitmodules` file and a `third_party/` directory, which is what that flag is for. Clone without it and the submodule contents are not in your working tree, so the third-party code the build expects is missing, and CMake fails partway through rather than telling you that you skipped a step. The rest of the layout says what a build produces and what a user reads: `include/` for the public headers, `db/` and `table/` for the storage internals, `port/` for the platform layer, `util/` for helpers, `benchmarks/` where the `db_bench` program used in the performance section lives, and `doc/` for the library documentation, which is online and bundled with the source code. The default branch is `main`, and that is also the branch contributors are told to rebase onto.

The POSIX build ends at cmake --build . with no install step

CMake is supported out of the box, and the POSIX quick start is two lines:

mkdir -p build && cd build
cmake -DCMAKE_BUILD_TYPE=Release .. && cmake --build .

That produces build artifacts inside the build directory and stops there. No install target is documented, no install prefix is named, and no binary package is published, so consuming the library means vendoring the source into your own build or pointing your build at this tree. Advanced usage is left to the CMake documentation and `CMakeLists.txt`. The consequence for anyone evaluating the library is that there is no package manager step to copy, and the first build is a compile of source you now own. That is a normal arrangement for an embedded library, but it means the version you depend on is a commit you pin rather than a version a package manager resolves. The project's license field is BSD-3-Clause and the tree carries a LICENSE file, with no additional grant or restriction described in the documentation.

The Visual Studio generator builds x86 unless you ask for Win64

Windows takes three documented steps, and the third is a trap for anyone targeting 64 bits:

mkdir build
cd build
cmake -G "Visual Studio 15" ..

That generates a solution which by default builds for x86. The 64-bit build is a different generator:

cmake -G "Visual Studio 15 Win64" ..

The solution then compiles from the command line:

devenv /build Debug leveldb.sln

or you open `leveldb.sln` in Visual Studio and build from inside it. The consequence is concrete rather than theoretical: run the documented generator once, assume it matched your target architecture, and the mismatch appears later as a pointer-size failure or a link error rather than at configure time. Note also what the project declines to cover. Contributions to build configuration files such as `CMakeLists.txt` are unlikely to be accepted, and the project is not currently interested in supporting other operating systems, compilers or build systems. A different toolchain, or a build file for your own packaging, is your fork to maintain.

The only performance numbers in the project were produced in 2011

The performance section is a single `db_bench` run, and it dates itself. The header records version 1.1, a run dated Sun May 1 12:11:26 2011, and hardware listed as 4 x Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz with 4096 KB of cache, against one million entries with 16 byte keys and 100 byte values compressing to about half their original size, a raw size of 110.6 MB and a file size of 62.9 MB. The write rows that follow are `fillseq` at 1.765 micros/op and 62.7 MB/s, `fillsync` at 268.409 micros/op and 0.4 MB/s over 10000 ops, `fillrandom` at 2.460 micros/op, and `overwrite` at 2.380 micros/op. The README itself calls the results somewhat noisy and good for a ballpark estimate, and it separates `fillsync`, which flushes from the operating system to the disk after every operation, from the other write benchmarks that leave data in the buffer cache. These numbers size nothing on a current machine. The useful reading is the contrast between rows: a random write works out to roughly 400,000 writes per second, while a `fillsync` operation is described as costing 0.3 milliseconds against a disk seek that typically takes 10.

The review queue takes critical fixes only, and 1.23 is from 2021

Two maintenance signals point the same way, and anyone planning a dependency should weigh both. The README opens with a banner saying the repository is receiving very limited maintenance and will review only two kinds of change: fixes for critical bugs such as data loss or memory corruption, and changes absolutely needed by internally supported leveldb clients, which typically fix breakage introduced by a language, standard library or OS update. The last push to the default branch was on 2026-03-11, and the newest GitHub release is 1.23, published 2021-02-23, following 1.22 on 2019-05-03 and 1.21 on 2019-03-29. What that means for you is specific. A patch for a newer standard library or OS has a genuine route in, since that is one of the two named categories, while a feature request or a refactor has none. A pull request also needs a Contributor License Agreement signed at https://cla.developers.google.com/, a test or an explanation of why one is not required, formatting run as

clang-format -i --style=file <file>

against the Google C++ Style Guide, and a squash and rebase onto google/leveldb/main to keep the commit timeline linear.

Editorial conclusion

Adopt leveldb when a single process owns the data and you want sorted key iteration with an atomic batch and a snapshot, and you are prepared to own the vendored source. Do not adopt it if you need two writers, a network hop, or an upstream that accepts features, since the review policy names only critical bug fixes and the newest release is 1.23 from 2021-02-23. Before you commit, check the comparator you pass in, because it defines the sort order every range query depends on.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes