Skip to content
RU

libmdbx Overview

Related: Installation and building · First steps · Restrictions and gotchas · Architecture · Textbook: Volume I "Fundamentals" · Improvements

libmdbx is an extremely fast, compact, powerful, embedded, transactional key-value database with the Apache-2.0 license, focused on building unique lightweight solutions.

  1. Allows a swarm of multi-threaded processes to ACIDly read and update several key-value maps and multimaps in a locally-shared database.

  2. Provides extraordinary performance with minimal overhead through memory mapping and O(log N) operation costs by virtue of the B+tree.

  3. Requires no maintenance and no crash recovery since no WAL is used — which may be a caveat for write-intensive workloads with durability requirements (see durability modes).

  4. Enforces serializability for writers through a single mutex and affords wait-free reads for parallel readers, while readers and writers do not block each other.

  5. Guarantees data integrity after a crash unless explicitly neglected in favor of write performance (durability modes).

  6. Supports Linux, Windows, macOS, HarmonyOS, Android, iOS, FreeBSD, Solaris, NetBSD, OpenBSD and other systems compliant with POSIX.1-2008.

  7. Compact and friendly for full embedding — a few flat source files, no internal threads and no server process; implements the core of the Berkeley DB API with many powerful extensions.

Historically, libmdbx is a deeply revised descendant of the legendary LMDB: it inherits all LMDB benefits, resolves several of its issues and adds a large set of improvements.

Key features

  • Key-value data model, keys are always sorted; range lookups including range query volume estimation.
  • Fully ACID through MVCC and copy-on-write.
  • Multiple tables/sub-databases within a single datafile; ultra-efficient multimap (dupsort) support: values are sorted, searchable and iterable, keys are stored without duplication.
  • Data is memory-mapped and accessible zero-copy: full scans are extremely fast; get(key) is accelerated by a shareable lock-free cache.
  • Reads scale linearly across CPUs; reader and writer transactions do not block each other; no conflicts and no deadlocks (writes are serialized).
  • Online hot backup; an append operation for bulk insertion of pre-sorted data.
  • Automatic on-the-fly database size adjustment; continuous zero-overhead compactification; explicit defragmentation.
  • Customizable page size; nested transactions; no WAL and no transaction journal — no maintenance required.

Limitations (summary)

Full treatment — Restrictions and gotchas.

Parameter Value
Page size a power of 2: 256…65536, default 4096
Key size up to ≈½ pagesize (2022 bytes for 4K pages, 32742 for 64K); zero length supported
Value size up to 0x7FF00000 bytes for maps; ≈½ pagesize for multimaps
Write transaction size up to 4.94 TiB (4K pages), 79.1 TiB (64K)
Database size up to ≈8.0 TiB (4K), ≈128.0 TiB (64K)
Maximum tables 32765
Writers at most one write transaction at a time

Gotchas (summary)

  • B+tree → page access is mostly random: SSDs provide a significant boost for large databases.
  • Shadow paging instead of WAL → syncing may be the bottleneck for write-intensive workloads.
  • MVCC + long-lived readers: heavy data alteration while a long-lived read transaction is active increases the working set and may exhaust the free space. Avoid long reads; use transaction parking and the Handle-Slow-Readers callback — details in restrictions.
  • Extraordinary speed requires care: a simple linear scan may beat complex indexes, and suboptimal code shows its cost only on large data.

Comparison with other databases

libmdbx is superior to the legendary LMDB in features and reliability while not being inferior in performance (the detailed catalog — Improvements). Briefly, versus the class of embedded stores:

  • a database can be shared by multiple processes without multi-process issues;
  • no problems moving cursors after deletion;
  • zero-overhead compactification: a database file can be shrunk/truncated;
  • excluding disk I/O time — up to ≈3× faster than BoltDB and up to 10–100,000× faster than BoltDB/LMDB in specific edge cases (reproducible with ioArena, make bench-quartet, including RocksDB and WiredTiger comparisons);
  • even more features compared to BoltDB and/or LMDB.

When to choose libmdbx

✅ A good fit: a local embedded store with ACID guarantees; many readers with moderate writes; zero-maintenance and out-of-the-box crash-safety; multi-process access within one machine; huge multimaps and range queries.

⚠️ Think twice: network/distributed use (libmdbx is not a network database); write-intensive workloads with strict durability demands on slow storage (fsync is the bottleneck — see durability modes); long-lived read transactions alongside heavy updates (see restrictions).

Bindings

The full list (several dozen) — the Bindings and Projects section of the home site; the most demanded: Rust (libmdbx-rs), Go (mdbx-go), Python (PyPi/libmdbx), .NET (libmdbx-dotnet), NodeJS (mdbxmou) and others.