HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
boltdb
bolt
Go2014–2023
boltdb / bolt · Archived

bolt

An embedded key/value database for Go.

19Distinct people
26Mentions
0Explicit recommenders
14.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

An embedded key/value database for Go.

GitHub

Where it is used

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year26 dated mentions

Observed mentions: 2014-05-12 03:20:17 UTC to 2023-06-16 07:21:15 UTC.

02462014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC716
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC101
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC404
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC404
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC404
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC303
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Bolt Bolt is a pure Go key/value store inspired by Howard Chu's LMDB project. The goal of the project is to provide a simple, fast, and reliable database for projects that don't require a full database server such as Postgres or MySQL. Since Bolt is meant to be used as such a low-level piece of functionality, simplicity is key. The API will be small and only focus on getting values and setting values. That's it. Project Status Bolt is stable, the API is fixed, and the file format is fixed. Full unit test coverage and randomized black box testing are used to ensure database consistency and thread safety. Bolt is currently used in high-load production environments serving databases as large as 1TB. Many companies such as Shopify and Heroku use Bolt-backed services every day. A message from the author The original goal of Bolt was to provide a simple pure Go key/value store and to not bloat the code with extraneous features. To that end, the project has been a success. However, this limited scope also means that the project is complete. Maintaining an open source database requires an immense amount of time and energy. Changes to the code can have unintended and sometimes catastrophic effects so even simple changes require hours and hours of careful testing and validation. Unfortunately I no longer have the time or energy to continue this work. Bolt is in a stable state and has years of successful production use. As such, I feel that leaving it in its current state is the most prudent course of action. If you are interested in using a more featureful version of Bolt, I suggest that you look at the CoreOS fork called bbolt. Ben Johnson (@benbjohnson) Table of Contents Getting Started Installing Opening a database Transactions Read-write transactions Read-only transactions Batch read-write transactions Managing transactions manually Using buckets Using key/value pairs Autoincrementing integer for the bucket Iterating over keys Prefix scans Range scans ForEach() Nested buckets Database backups Statistics Read-Only Mode Mobile Use (iOS/Android) Resources Comparison with other databases Postgres, MySQL, & other relational databases LevelDB, RocksDB LMDB Caveats & Limitations Reading the Source Other Projects Using Bolt Getting Started Installing To start using Bolt, install Go and run go get: $ go get github.com/boltdb/bolt/... This will retrieve the library and install the bolt command line utility into your $GOBIN path. Opening a database The top-level object in Bolt is a DB. It is represented as a single file on your disk and represents a consistent snapshot of your data. To open your database, simply use the bolt.Open() function: package main import ( "log" "github.com/boltdb/bolt" ) func main() { // Open the my.db data file in your current directory. // It will be created if it doesn't exist. db, err := bolt.Open("my.db", 0600, nil) if err != nil { log.Fatal(err) } defer db.Close() ... } Please note that Bolt obtains a file lock on the data file so multiple processes cannot open the same database at the same time. Opening an already open Bolt database will cause it to hang until the other process closes it. To prevent an indefinite wait you can pass a timeout option to the Open() function: db, err := bolt.Open("my.db", 0600, &bolt.Options{Timeout: 1 * time.Second}) Transactions Bolt allows only one read-write transaction at a time but allows as many read-only transactions as you want at a time. Each transaction has a consistent view of the data as it existed when the transaction started. Individual transactions and all objects created from them (e.g. buckets, keys) are not thread safe. To work with data in multiple goroutines you must start a transaction for each one or use locking to ensure only one goroutine accesses a transaction at a time. Creating transaction from the DB is thread safe. Read-only transactions and read-write transactions should not depend on one another and generally shouldn't be opened simultaneously in the same goroutine. This can cause a deadlock as the read-write transaction needs to periodically re-map the data file but it cannot do so while a read-only transaction is open. Read-write transactions To start a read-write transaction, you can use the DB.Update() function: err := db.Update(func(tx *bolt.Tx) error { ... return nil }) Inside the closure, you have a consistent view of the database. You commit the transaction by returning nil at the end. You can also rollback the transaction at any point by returning an error. All database operations are allowed inside a read-write transaction. Always check the return error as it will report any disk failures that can cause your transaction to not complete. If you return an error within your closure it will be passed through. Read-only transactions To start a read-only transaction, you can use the DB.View() function: err := db.View(func(tx *bolt.Tx) error { ... return nil }) You also get a consistent view of the database within this closure, however, no mutating operations are allowed within a read-only transaction. You can only retrieve buckets, retrieve values, and copy the database within a read-only transaction. Batch read-write transactions Each DB.Update() waits for disk to commit the writes. This overhead can be minimized by combining multiple updates with the DB.Batch() function: err := db.Batch(func(tx *bolt.Tx) error { ... return nil }) Concurrent Batch calls are opportunistically combined into larger transactions. Batch is only useful when there are multiple goroutines calling it. The trade-off is that Batch can call the given function multiple times, if parts of the transaction fail. The function must be idempotent and side effects must take effect only after a successful return from DB.Batch(). For example: don't display messages from inside the function, instead set variables in the enclosing scope: var id uint64 err := db.Batch(func(tx *bolt.Tx) error { // Find last
Read the full README on GitHub

What Hacker News says

26 sources
I mean, not really. The hard work was done by benbjohnson who is now working on https://litestream.io/ and https://fly.io/ He's the one who wrote BoltDB https://github.com/boltdb/bolt I just put a relatively thin layer on top of it. Now, to address your point more directly: I'm too stupid to figure out configuration, but not too stupid to figure out code. Code gets compiled and type checked. You can have tests, etc. Tractability for code is much higher than configuration. With configuration, you have to be really smart and keep many moving parts in your head. With code, you can be a bit dumb and lean heavily on the tooling.
In The Stupid Programmer Manifesto
Designing Data Intensive applications- specifically chapter 3 and 4 which deal with strategies and algorithms for storing and encoding data to be stored on disk and their pros and cons. Once you read that, I'll suggest reading the source of a simple embedded key-value database, I wouldn't bother with RDBMs as they are complex beasts and contain way more than you need. BoltDB is a good project to read the source of https://github.com/boltdb/bolt, the whole thing is <10k lines of code and is a full blown production grade system with ACID semantics so packs a lot in those 10k and isn't just merely a toy.
In Ask HN: Books on designing disk-optimized data structures?
The litestream project was created by https://github.com/benbjohnson who wrote https://github.com/boltdb/bolt (a key value store) which has been instrumental (from my point of view) in the Go community as one of the original choices for an embedded database as it was not only fast, but had transactions with stable snapshots. It was used by https://github.com/blevesearch/bleve, https://github.com/etcd-io/etcd, and number of other projects. These days, https://github.com/dgraph-io/badger is often favored because of it's improved write throughput.
In A database for 2022
For a single server, SQLite, or boltdb[0] I've never had to scale horizontally. I develop in Go and you can get very far along with just vertical scaling (aka beefier hardware). Therefore I can't give concrete examples of a distributed db-as-a-library. But all that you need is to extend the functions that fetch data to not just fetch from disk but from "peers" as well. For this to work you need servers (instances) to know about each other, and as you add more they also get added to their peers - sort of like a bittorrent network. I don't think it's difficult to do. SQLite might not be suited for being distributed (although RQlite[1] claims to have done it). Making a distributed data storage based on boltdb[0] is probably more feasible. Whatever the case, there's no reason why a data storage engine can't be a library, even if it's distribu
Read the rest
In Single dependency stacks
Humble suggestion / shameless plug: try using Sourcegraph to read through some of the excellent codebases mentioned in other posts. This is basically our prime use case (I'm one of the creators): reading through and understanding code structure with jump-to-def / find-refs / symbol search in your browser. I'd suggest starting with the main function and tracing through the static structure of the codebase from there: https://sourcegraph.com/github.com/golang/go/-/blob/src/net/... https://sourcegraph.com/github.com/mholt/caddy@master/-/blob... https://sourcegraph.com/github.com/btcsuite/btcd@master/-/bl... https://sourcegraph.com/github.com/camlistore/camlistore@mas... https://sourcegraph.com/github.com/boltdb/bolt@master/-/blob... https://sourcegraph.com/github.com/go-kit/kit/-/blob/example...
In Ask HN: Good Go codebases to read?
> We have tried with BoltDB. Its performance is really bad. BoltDB author here. I agree with you that Badger would beat Bolt in many performance benchmarks but it's an apples and oranges comparison. LSM tree key/value stores are write-optimized and generally lack transactional support. BoltDB is read-optimized and supports ACID transactions with serializable isolation. Transactions come with a cost but they're really important for most applications. Regarding benchmarks, LSMs typically excel in random and sequential write performance and do OK with random read performance. LSMs tend to be terrible for sequential scans since levels have to be merged at query time. B+trees are usually terrible at random write performance but can do well with sequential writes that are batched. They tend to have good random read performance and awesome seque
Read the rest
ntial scan performance. It comes down to using the right tool for the job. If you don't need transactions, Bolt is probably overkill. There's whole section on the BoltDB README about when not to use Bolt: https://github.com/boltdb/bolt#caveats--limitations > It is just badly implemented, acquires a global mutex lock across all reads and writes. You're welcome to your opinion about it being "badly implemented" but the global mutex lock across reads and writes is simply untrue. Writes are serialized so those have a database-wide lock. However, read transactions only briefly take a lock when they start and again when they stop so they can obtain a snapshot of the root node. That gives the transaction a point-in-time snapshot of the entire database for the length of the transaction without blocking other read or write transactions.
In Badger – A fast key-value store written natively in Go

Showing the 15 most recent of 26 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.