| Logo |
|
|
| Description |
LMDB (Lightning Memory-Mapped Database) is a embedded database for key-value data based on B+trees. It is fully ACID transactional. The key features of LMDB are that it uses a single-level store based on memory-map files, which means that the OS is responsible for managing the pages (like caching frequently uses pages). It uses
|
LMDB (Lightning Memory-Mapped Database) is a embedded database for key-value data based on B+trees. It is fully ACID transactional. The key features of LMDB are that it uses a single-level store based on memory-map files, which means that the OS is responsible for managing the pages (like caching frequently uses pages). It uses shared memory copy-on-write semantics with a single writer; readers do not block writers, writers do not block readers, and readers do not block readers. The system allows as many versions of data at any time as there are transactions (many read, one write). It also maintains a free list of pages to track and reuse pages instead of allocating memory each time.
|
| History |
LMDB was developed and maintained by the Symas Corporation to replace [Berkeley DB](/db/berkeley-db) in the OpenLDAP project.
|
LMDB was developed and maintained by the Symas Corporation to replace [Berkeley DB](/db/berkeley-db) in the OpenLDAP project.
|
| Start Year | 2011 | 2011 |
| End Year | — | — |
| Twitter URL | — | — |
| Countries | Ireland | Ireland |
| Former Names | LightningDB | LightningDB |
| Website URL | https://www.symas.com/lmdb/technical | https://www.symas.com/lmdb/technical |
| Docs URL | http://www.lmdb.tech/doc/ | http://www.lmdb.tech/doc/ |
| Source Repo URL | https://www.openldap.org/software/repo.html | https://www.openldap.org/software/repo.html |
| Blog URL | — | — |
| Wikipedia URL | https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database | https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database |
| Tags | — | — |
| Licenses |
OpenLDAP Public License
|
OpenLDAP Public License
|
| Operating Systems |
AIX
Android
BSD
Linux
Solaris
Windows
iOS
macOS
|
AIXAndroidBSDLinuxSolarisWindowsiOSmacOS
|
| Governance | — | — |
| Project Types |
Commercial
Open Source
|
CommercialOpen Source
|
| Supported Languages |
C++
|
C++
|
| Written In | — | — |
| Coding Agents | — | — |
| Developer Orgs |
Howard Chu
|
Howard Chu
|
| Derived From | — | — |
| Embedded Systems | — | — |
| Inspired By |
Berkeley DB
|
Berkeley DB
|
| Compatible With | — | — |
| Hosted Services | — | — |
| Acquisitions | — | — |
| Checkpoints |
In the event of a crash, the database starts of from where it was left, the OS takes care of writing data to disk and the database here doesn't need to take any snapshots. The on-disk representation is similar to the in-memory representation, there is no provision for compressing the data, due the memory map constraints.
|
In the event of a crash, the database starts of from where it was left, the OS takes care of writing data to disk and the database here doesn't need to take any snapshots. The on-disk representation is similar to the in-memory representation, there is no provision for compressing the data, due the memory map constraints.
|
| Compression | — | — |
| Concurrency Control |
Multi-version Concurrency Control (MVCC)
Locking overhead avoided by using MVCC, readers don't block at all and writers don't block readers. Deleted versions are reclaimed by the free space management module of LMDB (essentially stored into a B+ tree for later use).
|
Multi-version Concurrency Control (MVCC)
Locking overhead avoided by using MVCC, readers don't block at all and writers don't block readers. Deleted versions are reclaimed by the free space management module of LMDB (essentially stored into a B+ tree for later use).
|
| Data Model |
Key-Value
This embedded database is a key-value in the backend, which is stored in the memory-map. The keys are indexed in a B+ tree. LMDB provides transactional guarantees on top of this key-value store. It is not a relational database.
|
Key-Value
This embedded database is a key-value in the backend, which is stored in the memory-map. The keys are indexed in a B+ tree. LMDB provides transactional guarantees on top of this key-value store. It is not a relational database.
|
| Foreign Keys | — | — |
| Hardware Acceleration | — | — |
| Indexes |
B+Tree
LMDB uses a modified design of B+ Tree with an append-only enhancement, and it uses 2 B+ trees : one for maintaining the regular user data pages and one for maintaining the free pages obtained after deletes. LMDB is optimized for read transactions. Due to use of Copy-on-Write, readers never block writers, therefore read transactions, by using older pages, may live indefinitely without affecting write transactions.
|
B+Tree
LMDB uses a modified design of B+ Tree with an append-only enhancement, and it uses 2 B+ trees : one for maintaining the regular user data pages and one for maintaining the free pages obtained after deletes. LMDB is optimized for read transactions. Due to use of Copy-on-Write, readers never block writers, therefore read transactions, by using older pages, may live indefinitely without affecting write transactions.
|
| Isolation Levels |
Serializable
LMDB provides Serializable isolation with MVCC, this is possible because of the single-writer semantics. Only a single write transaction can can be alive at a single point of time, hence no races among multiple writers modifying the database.
|
Serializable
LMDB provides Serializable isolation with MVCC, this is possible because of the single-writer semantics. Only a single write transaction can can be alive at a single point of time, hence no races among multiple writers modifying the database.
|
| Joins |
Not Supported
|
Not Supported
|
| Logging |
Shadow Paging
No logging procedures are implemented here, using copy-on-write semantics (with shadow paging) provides durability without any need for logging. Shadow paging allows new writes to a different location and not directly replace the existing pages, hence avoids data-corruption. Also the shadow page reference update is atomic, hence avoids need for logging.
|
Shadow Paging
No logging procedures are implemented here, using copy-on-write semantics (with shadow paging) provides durability without any need for logging. Shadow paging allows new writes to a different location and not directly replace the existing pages, hence avoids data-corruption. Also the shadow page reference update is atomic, hence avoids need for logging.
|
| Parallel Execution | — | — |
| Query Compilation |
Not Supported
|
Not Supported
|
| Query Execution |
Tuple-at-a-Time Model
There is no query planning or query execution options as this is an embedded database, since we operate at individual key level, the closest we can classify it is under tuple-at-a-time. The user can program custom querying models on top this embeddded database, which can support other query execution options.
|
Tuple-at-a-Time Model
There is no query planning or query execution options as this is an embedded database, since we operate at individual key level, the closest we can classify it is under tuple-at-a-time. The user can program custom querying models on top this embeddded database, which can support other query execution options.
|
| Query Interface |
Custom API
LMDB has no SQL layer but applications can directly access the database using API calls provided by LMDB. API support is not just in C but many wrappers for other languages have been developed by open-source contributors. All key-value store operations can be performed using these API calls.
|
Custom API
LMDB has no SQL layer but applications can directly access the database using API calls provided by LMDB. API support is not just in C but many wrappers for other languages have been developed by open-source contributors. All key-value store operations can be performed using these API calls.
|
| Storage Architecture |
In-Memory
LMDB uses mmap, hence it reliquishes most of the caching control to the OS. Memory map allows zero-copies for read/write and no additional buffers for the transaction control. Supports larger-than memory databases, it is bounded by the size of the virtual memory since they use a memory map.
|
In-Memory
LMDB uses mmap, hence it reliquishes most of the caching control to the OS. Memory map allows zero-copies for read/write and no additional buffers for the transaction control. Supports larger-than memory databases, it is bounded by the size of the virtual memory since they use a memory map.
|
| Storage Format | — | — |
| Storage Model |
Custom
They use a memory-map to store the database with copy-on-write semantics, hence no specific storage model but the semantics are left to the operating system. The on-disk representation is similar to the memory representation of the database.
|
Custom
They use a memory-map to store the database with copy-on-write semantics, hence no specific storage model but the semantics are left to the operating system. The on-disk representation is similar to the memory representation of the database.
|
| Storage Organization | — | — |
| Stored Procedures |
Not Supported
|
Not Supported
|
| System Architecture |
Shared-Memory
LMDB uses shared-memory model i.e. it handles the memory as a single address space and all the threads access this in parallel. It uses copy-on-write semantics.
|
Shared-Memory
LMDB uses shared-memory model i.e. it handles the memory as a single address space and all the threads access this in parallel. It uses copy-on-write semantics.
|
| Views |
Not Supported
|
Not Supported
|