BoltDB is an embedded key/value database written in Go. With shadow paging and MVCC by allowing only one writer and multiple readers, it guarantees ACID properties as well as fully serializable transactions. BoltDB stores key/value pairs in B+tree data storage, which allows fast read access. Since BoltDB only deals with a single file at a time, it performs better at recovery from a system crash.


In 2011, Howard Chu introduced MDB, a memory-mapped database backend for OpenLDAP, later renamed to [LMDB] ( Memory-Mapped Database). In 2013, BoltDB was initially started by Ben Johnson as a port of LMDB to Go, but then the two projects diverged as the author of Bolt decided to focus on simplicity and providing the easy-to-use Go API. The goal of BoltDB became to provide a simple, fast, and reliable database for projects that don't require a full database server such as Postgres or MySQL. With BoltDB being stable, its API fixed, and its file format fixed, the author considered the project a success. Leaving it in such a state, the project was abandoned by its author in 2017.

Query Interface

Custom API

BoltDB supports basic key/value queries such as insert, delete and update with its own APIs. All `bucket` operations are organized and monitored by transactions `Tx`. For example, transactions have the ability to create a bucket or remove a bucket. Buckets support basic key/value query operations that involve read, write and delete. Since BoltDB stores its key in byte-sorted order within a bucket, it supports sequential iteration over a bucket with a cursor. The cursor allows moving to the first key, the last key, the previous key, the next key, and a specific key in a bucket. BoltDB performs a prefix scan by using the cursor to locate specific keys with the required prefix. It performs a range scan by using the cursor to find keys that satisfy a comparison predicate. Besides the cursor, the bucket also supports self-iterating over all key/value pairs in a bucket with a foreach function.


Virtual Views

Bolt allows only one read-write transaction at a time but allows as many read-only transactions as requested. The view obtained by each transaction is consistent with the data present at the beginning of the transaction. BoltDB recommends three types of transactions: read-write transactions with `DB.Update`, read-only transactions with `DB.View` and batch read-write transactions with `DB.Batch`. Along with the three recommended transactions, BoltDB also allows manual transaction management with `DB.Begin`.

Concurrency Control

Multi-version Concurrency Control (MVCC)

BoltDB supports lock-free MVCC using a single writer and multiple readers. It allows only one read-write transaction at a time but allows multiple read-only transactions at the same time. Allowing read-only transactions and read-write transactions depend on one another can cause deadlocks since if there exists a reader, another writer cannot periodically remap the file as needed by copy-on-write. Similarly, the co-occurrence of read-only transactions and read-write transactions in the same goroutine should also be avoided due to the same reason.


Not Supported

Bolt saves data into a single memory-mapped file on disk. It doesn’t have a separate journal or write-ahead log.

Storage Model


BoltDB uses key/value storage, which does not involve rows or columns.

Isolation Levels


BoltDB supports fully serializable ACID transactions. It allows only one read-write transaction at a time but allows as many read-only transactions as requested. When opening a database, BoltDB obtains a file lock on the data file which prevents multiple processes from accessing the same database at the same time. A process will hang upon attempting to open an already open Bolt database until the process that opens the database closes it. BoltDB supports the ability to prevent an indefinite wait by passing a timeout option upon opening a database.



BoltDB stores key/value pairs in a B+ tree. The B+ tree has a cursor that is able to find a specific key or move freely up and down the tree.

Storage Architecture


There are only a few types in BoltDB: `DB`, `Bucket`, `Tx`, and `Cursor`. - The `DB` is a single file represented by pages on disk. Each page is commonly 4096 Bytes. The first two pages of the file store the metadata that keeps track of version, transaction id, and page size of the database, as well as the locations of the `freelist` and the first page id of data. The third page stores a `freelist`that keeps track the page id's of the free pages. The rest of the pages are the collection of buckets that store the key/value paris. - A `Bucket` is a collection of unique keys that are associated with values. Each bucket is represented using a B+ tree. When accessing a B+ tree, the nodes in the corresponding page are fetched into memory. The B+ tree used in BoltDB is different from common B+tree in the following aspects: - While B+ trees typically have n+1 values and n keys in each node, the number of values and the number of keys are equal in BoltDB B+ tree. - In BoltDB B+ tree, the value field in a non-leaf node stores the page id of its child node and the corresponding key stores the first key in the child node. - There are no pointers between sibling leaf nodes in BoltDB B+ tree.

Data Model


Bolt is a key-value store that provides an ordered map, which allows easy access and lookup. All collections of key/value pairs are stored in buckets within which all keys must be unique. The keys are stored in byte-sorted order within a bucket. A bucket can be created with `Tx.CreateBucket` or `Tx.CreateBucketIfNotEXists` so that it can be created only if it doesn't exist.

Storage Organization

Copy-on-Write / Shadow Paging

BoltDB saves data into a single memory-mapped file on disk. Write-ahead log is not necessary since BoltDB only deals with one file at a time. With copy-on-write, when writing to a page, BoltDB makes updates on the copy of the original page and updates the pointer to point at the new page upon commit.

BoltDB Logo

Source Code

Tech Docs


Ben Johnson

Country of Origin


Start Year


End Year


Project Type

Open Source

Written in


Supported languages


Inspired By


Operating Systems

Android, BSD, iOS, Linux, OS X, Solaris, Windows