LMDB 1.0 serves data straight from a memory map — zero malloc, zero memcpy on any fetch, full ACID transactions, and not a single write-ahead log in sight.
That architecture, documented in the fresh 1.0 release notes, is the reason you can drop this embedded database into a process and never worry about checkpointing, compaction, or recovery after a crash. Write-ahead loggers and append-only stores grow without bound unless you periodically clean them; LMDB tracks free pages inside its own file and reuses them on every write, so the database size stabilizes.
How LMDB Avoids the Checkpointing Tax
No page cache layer. No separate WAL. The entire Btree sits in a single memory-mapped file. Read transactions just dereference pointers into that map, which means they run with zero locks and never block writers. Writers use copy-on-write: active pages are never overwritten, so a crash at any point leaves the database consistent. No recovery procedure. No fsck.
Writes are fully serialized — only one write transaction at a time — which eliminates deadlocks between writers. Multi-version concurrency keeps readers out of the lock path entirely. The cost is that stale read transactions can pin freed pages, causing the database file to balloon until those readers are cleared. The mdb_reader_check function or mdb_stat tool handles that; the maintainers recommend periodic checks.
The Cost of Immunity to Corruption
By default, the memory map is read-only. Stray pointer writes from application bugs cannot corrupt the database. You pay a small write performance penalty because the library must copy data into the map via the kernel. Flip the map to read-write (MDB_WRITEMAP) and write throughput jumps, but you lose corruption immunity — if your code has a wild pointer, the database file gets trashed.
There are other caveats baked into the 1.0 docs that every operator should know. Data file initialisation changed in version 0.9.10: unused chunks used to contain garbage from freed heap memory; now they get zeroed before writing, which prevents information leaks but adds a small write overhead. The MDB_NOMEMINIT flag suppresses that, but if you handle sensitive data you should not use it. Also, never have the same LMDB environment open twice in one process — doing so breaks the underlying fcntl() advisory locking.
What 1.0 Changes for Production Use
The 1.0 label signals API stability after years of 0.9 releases. The documented restrictions — one transaction per thread, no fork() survivors, robust mutex handling on Linux, semaphore quirks on BSD — haven't changed, but they're now part of a hardened spec. If you were already running LMDB in production, the upgrade from 0.9 should be straightforward (the migration guide lives in the same doc tree). If you're new: you get a zero-copy, crash-proof, no-maintenance key-value store that fits in any process address space. Just don't leave reader transactions lying around.
Source: Lightning Memory-Mapped Database Manager (LMDB) 1.0
Domain: lmdb.tech
Comments load interactively on the live page.