bbolt

Overview

bbolt is an embedded key-value database for Go applications that need local storage without a separate database server. It suits developers building read-heavy software around a single database file; its one-writer rule and slow random writes make write-heavy or multi-process workloads a poor fit.

Key features

Data lives in one disk file, organized into buckets that can be nested. Keys are stored in byte-sorted order, making range scans a natural fit. The file represents a consistent snapshot, which keeps the storage model straightforward for applications that can manage their own database access.

Transactions are serializable and ACID-compliant, but only one read-write transaction can run at a time. Multiple read-only transactions can run concurrently. That arrangement favors workloads with frequent reads and controlled writes; it can bottleneck applications that need parallel writers. A read-only transaction can also create a consistent hot backup without blocking other reads or writes.

bbolt exposes operation statistics for logging or sending to a service such as statsd. The project documents gomobile bindings for using database logic on iOS and Android. Go developers can install the library with go get go.etcd.io/bbolt@latest and its command-line utility with go install go.etcd.io/bbolt/cmd/bbolt@latest.

Pricing

bbolt — free. The open-source Go library and command-line utility are free, with no paid plans listed. There is no free trial because there is no paid tier to trial. The project identifies an MIT license, making cost a non-issue for teams choosing among database libraries; users seeking a paid support plan should look elsewhere.

Platforms

The project supports Windows, macOS, Linux, iOS, and Android. Mobile use is documented through gomobile bindings. bbolt is an embedded library rather than a database server, so platform support does not remove the constraint that multiple processes cannot share a database file for writing.

Who it's for

bbolt is best for Go developers who want a compact embedded store for read-intensive workloads, sorted-key range scans, and applications that benefit from a single-file snapshot. It is less suitable when multiple processes must write the same database, writes need to happen concurrently, or random writes dominate. Databases can exceed physical RAM if the memory map fits the process's virtual address space, but this can be problematic on 32-bit systems. Deleting substantial data does not shrink the file: freed pages remain available for reuse instead.

Pros and cons

• Pros: Serializable ACID transactions and concurrent readers suit applications that need consistent reads without a server.
• Pros: Hot backups can be written from a read-only transaction without interrupting other database activity.
• Pros: Sorted bucket keys make range scans well matched to the storage model.
• Cons: One read-write transaction at a time limits write concurrency and can constrain throughput.
• Cons: The exclusive write lock prevents multiple processes from sharing a file for writing; random writes can also be slow.
• Cons: Deleting data does not reclaim disk space, and large memory-mapped databases may pose problems on 32-bit systems.

Alternatives

For other embedded database options, browse Embedded Databases.

• Chroma is worth considering for a freemium option with a free plan and an open-source codebase also used for Chroma Cloud.
• LadybugDB is another free, MIT-licensed option, with source code and pre-compiled binaries.
• RxDB may suit projects that need replication and realtime sync in its free core plan.
• SQLite is a free embedded SQL engine with no separate server process, a better match when an SQL database model is needed.
• EJDB2 is another free, MIT-licensed open-source database engine.
• ObjectBox offers a free core database plan and a trial for its freemium product.
• PouchDB is a free, open-source alternative.
• Qdrant offers a free cloud tier for a single-node cluster with specified compute, memory, and disk allowances.

Verdict

Choose bbolt for a Go application that needs a free, embedded key-value store with consistent transactions, concurrent reads, and non-blocking hot backups. Its single-file design and sorted keys are compelling for read-heavy workloads, but the one-writer limit, process-level write lock, and slow random writes are strong reasons to choose another database when write concurrency is central.