leveldb

LevelDB, written at Google, maps string keys to string values in sorted order. The project sits at roughly 39,000 stars on GitHub, yet its maintenance list is deliberately short.

The one line description is simple: a fast key value storage library written at Google that provides an ordered mapping from string keys to string values. The repository repeats that line and then gets down to business. Keys and values are arbitrary byte arrays. Data stays sorted by key, unless callers supply a custom comparison function to override the order. The core operations are Put, Get, and Delete, and several changes can be packed into one atomic batch. Transient snapshots give a consistent view, iteration runs forward and backward, and Snappy compression is automatic, with Zstd as an option. File system and other OS activity passes through a virtual interface, so the environment layer can be swapped out.

The limitations are spelled out plainly. This is not a SQL database. There is no relational data model, no SQL queries, and no support for indexes. Only a single process, possibly multi-threaded, may touch a given database at a time, and no client server mode is built in. Anyone who needs that has to wrap their own server around the library. It is a compact, honest statement of scope, and most of the value in reading it is finding out what the library will not do.

The repository is in a very limited maintenance state. Only two kinds of changes get reviewed: fixes for critical bugs, such as data loss or memory corruption, and changes absolutely needed by internally supported leveldb clients, typically breakage introduced by a language, standard library, or OS update. Pull requests need a signed Contributor License Agreement and a single commit rebased on main. Changes only get considered for tested platforms, meaning POSIX on Linux and macOS, or Windows. The API is treated as stable, so changes that would force downstream projects to adapt may be rejected.

The README ships a performance report from the included db_bench program. The setup is small: a million entries, keys of 16 bytes, values of 100 bytes, compressing to about half their size. The results are described as somewhat noisy, but enough for a ballpark estimate. Compaction runs in the background, and read performance improves after it settles.

• Source 1 · Project repository
• Source 2 · README