Repository files navigation

bbolt is a fork ofBen Johnson'sBolt key/valuestore. The purpose of this fork is to provide the Go community with an activemaintenance and development target for Bolt; the goal is improved reliabilityand stability. bbolt includes bug fixes, performance enhancements, and featuresnot found in Bolt while preserving backwards compatibility with the Bolt API.

Bolt is a pure Go key/value store inspired byHoward Chu'sLMDB project. The goal of the project is to provide a simple,fast, and reliable database for projects that don't require a full databaseserver 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 valuesand setting values. That's it.

Bolt is stable, the API is fixed, and the file format is fixed. Full unittest coverage and randomized black box testing are used to ensure databaseconsistency and thread safety. Bolt is currently used in high-load productionenvironments serving databases as large as 1TB. Many companies such asShopify and Heroku use Bolt-backed services every day.

bbolt usessemantic versioning.API should not change between patch and minor releases.New minor versions may add additional features to the API.

• 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
• Known Issues
• Other Projects Using Bolt

To start usingbbolt, install Go and rungo get:

$ go get go.etcd.io/bbolt@latest

This will retrieve the library and update yourgo.mod andgo.sum files.

To run the command line utility, execute:

$ go run go.etcd.io/bbolt/cmd/bbolt@latest

Rungo install to install thebbolt command line utility intoyour$GOBIN path, which defaults to$GOPATH/bin or$HOME/go/bin if theGOPATH environment variable is not set.

$ go install go.etcd.io/bbolt/cmd/bbolt@latest

To use bbolt as an embedded key-value store, import as:

import bolt"go.etcd.io/bbolt"db,err:=bolt.Open(path,0600,nil)iferr!=nil {returnerr}deferdb.Close()

The top-level object in Bolt is aDB. It is represented as a single file onyour disk and represents a consistent snapshot of your data.

To open your database, simply use thebolt.Open() function:

package mainimport ("log"bolt"go.etcd.io/bbolt")funcmain() {// 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)iferr!=nil {log.Fatal(err)}deferdb.Close()...}

Please note that Bolt obtains a file lock on the data file so multiple processescannot open the same database at the same time. Opening an already open Boltdatabase will cause it to hang until the other process closes it. To preventan indefinite wait you can pass a timeout option to theOpen() function:

db,err:=bolt.Open("my.db",0600,&bolt.Options{Timeout:1*time.Second})

Bolt allows only one read-write transaction at a time but allows as manyread-only transactions as you want at a time. Each transaction has a consistentview 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 starta transaction for each one or use locking to ensure only one goroutine accessesa transaction at a time. Creating transaction from theDB is thread safe.

Transactions should not depend on one another and generally shouldn't be openedsimultaneously in the same goroutine. This can cause a deadlock as the read-writetransaction needs to periodically re-map the data file but it cannot do so whileany read-only transaction is open. Even a nested read-only transaction can causea deadlock, as the child transaction can block the parent transaction from releasingits resources.

To start a read-write transaction, you can use theDB.Update() function:

err:=db.Update(func(tx*bolt.Tx)error {...returnnil})

Inside the closure, you have a consistent view of the database. You commit thetransaction by returningnil at the end. You can also rollback the transactionat any point by returning an error. All database operations are allowed insidea read-write transaction.

Always check the return error as it will report any disk failures that can causeyour transaction to not complete. If you return an error within your closureit will be passed through.

To start a read-only transaction, you can use theDB.View() function:

err:=db.View(func(tx*bolt.Tx)error {...returnnil})

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 onlyretrieve buckets, retrieve values, and copy the database within a read-onlytransaction.

EachDB.Update() waits for disk to commit the writes. This overheadcan be minimized by combining multiple updates with theDB.Batch()function:

err:=db.Batch(func(tx*bolt.Tx)error {...returnnil})

Concurrent Batch calls are opportunistically combined into largertransactions. Batch is only useful when there are multiple goroutinescalling it.

The trade-off is thatBatch can call the givenfunction multiple times, if parts of the transaction fail. Thefunction must be idempotent and side effects must take effect onlyafter a successful return fromDB.Batch().

For example: don't display messages from inside the function, insteadset variables in the enclosing scope:

variduint64err:=db.Batch(func(tx*bolt.Tx)error {// Find last key in bucket, decode as bigendian uint64, increment// by one, encode back to []byte, and add new key....id=newValuereturnnil})iferr!=nil {return...}fmt.Println("Allocated ID %d",id)

TheDB.View() andDB.Update() functions are wrappers around theDB.Begin()function. These helper functions will start the transaction, execute a function,and then safely close your transaction if an error is returned. This is therecommended way to use Bolt transactions.

However, sometimes you may want to manually start and end your transactions.You can use theDB.Begin() function directly butplease be sure to closethe transaction.

// Start a writable transaction.tx,err:=db.Begin(true)iferr!=nil {returnerr}defertx.Rollback()// Use the transaction..._,err:=tx.CreateBucket([]byte("MyBucket"))iferr!=nil {returnerr}// Commit the transaction and check for error.iferr:=tx.Commit();err!=nil {returnerr}

The first argument toDB.Begin() is a boolean stating if the transactionshould be writable.

Buckets are collections of key/value pairs within the database. All keys in abucket must be unique. You can create a bucket using theTx.CreateBucket()function:

db.Update(func(tx*bolt.Tx)error {b,err:=tx.CreateBucket([]byte("MyBucket"))iferr!=nil {returnfmt.Errorf("create bucket: %s",err)}returnnil})

You can retrieve an existing bucket using theTx.Bucket() function:

db.Update(func(tx*bolt.Tx)error {b:=tx.Bucket([]byte("MyBucket"))ifb==nil {returnerrors.New("bucket does not exist")}returnnil})

You can also create a bucket only if it doesn't exist by using theTx.CreateBucketIfNotExists() function. It's a common pattern to call thisfunction for all your top-level buckets after you open your database so you canguarantee that they exist for future transactions.

To delete a bucket, simply call theTx.DeleteBucket() function.

You can also iterate over all existing top-level buckets withTx.ForEach():

db.View(func(tx*bolt.Tx)error {tx.ForEach(func(name []byte,b*bolt.Bucket)error {fmt.Println(string(name))returnnil})returnnil})

To save a key/value pair to a bucket, use theBucket.Put() function:

db.Update(func(tx*bolt.Tx)error {b:=tx.Bucket([]byte("MyBucket"))err:=b.Put([]byte("answer"), []byte("42"))returnerr})

This will set the value of the"answer" key to"42" in theMyBucketbucket. To retrieve this value, we can use theBucket.Get() function:

db.View(func(tx*bolt.Tx)error {b:=tx.Bucket([]byte("MyBucket"))v:=b.Get([]byte("answer"))fmt.Printf("The answer is: %s\n",v)returnnil})

TheGet() function does not return an error because its operation isguaranteed to work (unless there is some kind of system failure). If the keyexists then it will return its byte slice value. If it doesn't exist then itwill returnnil. It's important to note that you can have a zero-length valueset to a key which is different than the key not existing.

Use theBucket.Delete() function to delete a key from the bucket:

db.Update(func (tx*bolt.Tx)error {b:=tx.Bucket([]byte("MyBucket"))err:=b.Delete([]byte("answer"))returnerr})

This will delete the keyanswers from the bucketMyBucket.

Please note that values returned fromGet() are only valid while thetransaction is open. If you need to use a value outside of the transactionthen you must usecopy() to copy it to another byte slice.

By using theNextSequence() function, you can let Bolt determine a sequencewhich can be used as the unique identifier for your key/value pairs. See theexample below.

// CreateUser saves u to the store. The new user ID is set on u once the data is persisted.func (s*Store)CreateUser(u*User)error {returns.db.Update(func(tx*bolt.Tx)error {// Retrieve the users bucket.// This should be created when the DB is first opened.b:=tx.Bucket([]byte("users"))// Generate ID for the user.// This returns an error only if the Tx is closed or not writeable.// That can't happen in an Update() call so I ignore the error check.id,_:=b.NextSequence()u.ID=int(id)// Marshal user data into bytes.buf,err:=json.Marshal(u)iferr!=nil {returnerr        }// Persist bytes to users bucket.returnb.Put(itob(u.ID),buf)    })}// itob returns an 8-byte big endian representation of v.funcitob(vint) []byte {b:=make([]byte,8)binary.BigEndian.PutUint64(b,uint64(v))returnb}typeUserstruct {IDint...}

Bolt stores its keys in byte-sorted order within a bucket. This makes sequentialiteration over these keys extremely fast. To iterate over keys we'll use aCursor:

db.View(func(tx*bolt.Tx)error {// Assume bucket exists and has keysb:=tx.Bucket([]byte("MyBucket"))c:=b.Cursor()fork,v:=c.First();k!=nil;k,v=c.Next() {fmt.Printf("key=%s, value=%s\n",k,v)}returnnil})

The cursor allows you to move to a specific point in the list of keys and moveforward or backward through the keys one at a time.

The following functions are available on the cursor:

First()  Move to the first key.Last()   Move to the last key.Seek()   Move to a specific key.Next()   Move to the next key.Prev()   Move to the previous key.

Each of those functions has a return signature of(key []byte, value []byte).You must seek to a position usingFirst(),Last(), orSeek() before callingNext() orPrev(). If you do not seek to a position then these functions willreturn anil key.

When you have iterated to the end of the cursor, thenNext() will return anil key and the cursor still points to the last element if present. When youhave iterated to the beginning of the cursor, thenPrev() will return anilkey and the cursor still points to the first element if present.

If you remove key/value pairs during iteration, the cursor may automaticallymove to the next position if present in current node each time removing a key.When you callc.Next() after removing a key, it may skip one key/value pair.Refer topull/611 to get more detailed info.

During iteration, if the key is non-nil but the value isnil, that meansthe key refers to a bucket rather than a value. UseBucket.Bucket() toaccess the sub-bucket.

To iterate over a key prefix, you can combineSeek() andbytes.HasPrefix():

db.View(func(tx*bolt.Tx)error {// Assume bucket exists and has keysc:=tx.Bucket([]byte("MyBucket")).Cursor()prefix:= []byte("1234")fork,v:=c.Seek(prefix);k!=nil&&bytes.HasPrefix(k,prefix);k,v=c.Next() {fmt.Printf("key=%s, value=%s\n",k,v)}returnnil})

Another common use case is scanning over a range such as a time range. If youuse a sortable time encoding such as RFC3339 then you can query a specificdate range like this:

db.View(func(tx*bolt.Tx)error {// Assume our events bucket exists and has RFC3339 encoded time keys.c:=tx.Bucket([]byte("Events")).Cursor()// Our time range spans the 90's decade.min:= []byte("1990-01-01T00:00:00Z")max:= []byte("2000-01-01T00:00:00Z")// Iterate over the 90's.fork,v:=c.Seek(min);k!=nil&&bytes.Compare(k,max)<=0;k,v=c.Next() {fmt.Printf("%s: %s\n",k,v)}returnnil})

Note that, while RFC3339 is sortable, the Golang implementation of RFC3339Nano does not use a fixed number of digits after the decimal point and is therefore not sortable.

You can also use the functionForEach() if you know you'll be iterating overall the keys in a bucket:

db.View(func(tx*bolt.Tx)error {// Assume bucket exists and has keysb:=tx.Bucket([]byte("MyBucket"))b.ForEach(func(k,v []byte)error {fmt.Printf("key=%s, value=%s\n",k,v)returnnil})returnnil})

Please note that keys and values inForEach() are only valid whilethe transaction is open. If you need to use a key or value outside ofthe transaction, you must usecopy() to copy it to another byteslice.

You can also store a bucket in a key to create nested buckets. The API is thesame as the bucket management API on theDB object:

func (*Bucket)CreateBucket(key []byte) (*Bucket,error)func (*Bucket)CreateBucketIfNotExists(key []byte) (*Bucket,error)func (*Bucket)DeleteBucket(key []byte)error

Say you had a multi-tenant application where the root level bucket was the account bucket. Inside of this bucket was a sequence of accounts which themselves are buckets. And inside the sequence bucket you could have many buckets pertaining to the Account itself (Users, Notes, etc) isolating the information into logical groupings.

// createUser creates a new user in the given account.funccreateUser(accountIDint,u*User)error {// Start the transaction.tx,err:=db.Begin(true)iferr!=nil {returnerr    }defertx.Rollback()// Retrieve the root bucket for the account.// Assume this has already been created when the account was set up.root:=tx.Bucket([]byte(strconv.FormatUint(accountID,10)))// Setup the users bucket.bkt,err:=root.CreateBucketIfNotExists([]byte("USERS"))iferr!=nil {returnerr    }// Generate an ID for the new user.userID,err:=bkt.NextSequence()iferr!=nil {returnerr    }u.ID=userID// Marshal and save the encoded user.ifbuf,err:=json.Marshal(u);err!=nil {returnerr    }elseiferr:=bkt.Put([]byte(strconv.FormatUint(u.ID,10)),buf);err!=nil {returnerr    }// Commit the transaction.iferr:=tx.Commit();err!=nil {returnerr    }returnnil}

Bolt is a single file so it's easy to backup. You can use theTx.WriteTo()function to write a consistent view of the database to a writer. If you callthis from a read-only transaction, it will perform a hot backup and not blockyour other database reads and writes.

By default, it will use a regular file handle which will utilize the operatingsystem's page cache. See theTxdocumentation for information about optimizing for larger-than-RAM datasets.

One common use case is to backup over HTTP so you can use tools likecURL todo database backups:

funcBackupHandleFunc(w http.ResponseWriter,req*http.Request) {err:=db.View(func(tx*bolt.Tx)error {w.Header().Set("Content-Type","application/octet-stream")w.Header().Set("Content-Disposition",`attachment; filename="my.db"`)w.Header().Set("Content-Length",strconv.Itoa(int(tx.Size())))_,err:=tx.WriteTo(w)returnerr})iferr!=nil {http.Error(w,err.Error(),http.StatusInternalServerError)}}

Then you can backup using this command:

$ curl http://localhost/backup> my.db

Or you can open your browser tohttp://localhost/backup and it will downloadautomatically.

If you want to backup to another file you can use theTx.CopyFile() helperfunction.

The database keeps a running count of many of the internal operations itperforms so you can better understand what's going on. By grabbing a snapshotof these stats at two points in time we can see what operations were performedin that time range.

For example, we could start a goroutine to log stats every 10 seconds:

gofunc() {// Grab the initial stats.prev:=db.Stats()for {// Wait for 10s.time.Sleep(10*time.Second)// Grab the current stats and diff them.stats:=db.Stats()diff:=stats.Sub(&prev)// Encode stats to JSON and print to STDERR.json.NewEncoder(os.Stderr).Encode(diff)// Save stats for the next loop.prev=stats}}()

It's also useful to pipe these stats to a service such as statsd for monitoringor to provide an HTTP endpoint that will perform a fixed-length sample.

Sometimes it is useful to create a shared, read-only Bolt database. To this,set theOptions.ReadOnly flag when opening your database. Read-only modeuses a shared lock to allow multiple processes to read from the database butit will block any processes from opening the database in read-write mode.

db,err:=bolt.Open("my.db",0600,&bolt.Options{ReadOnly:true})iferr!=nil {log.Fatal(err)}

Bolt is able to run on mobile devices by leveraging the binding feature of thegomobile tool. Create a struct that willcontain your database logic and a reference to a*bolt.DB with a initializingconstructor that takes in a filepath where the database file will be stored.Neither Android nor iOS require extra permissions or cleanup from using this method.

funcNewBoltDB(filepathstring)*BoltDB {db,err:=bolt.Open(filepath+"/demo.db",0600,nil)iferr!=nil {log.Fatal(err)}return&BoltDB{db}}typeBoltDBstruct {db*bolt.DB...}func (b*BoltDB)Path()string {returnb.db.Path()}func (b*BoltDB)Close() {b.db.Close()}

Database logic should be defined as methods on this wrapper struct.

To initialize this struct from the native language (both platforms now synctheir local storage to the cloud. These snippets disable that functionality for thedatabase file):

Stringpath;if (android.os.Build.VERSION.SDK_INT >=android.os.Build.VERSION_CODES.LOLLIPOP){path =getNoBackupFilesDir().getAbsolutePath();}else{path =getFilesDir().getAbsolutePath();}Boltmobiledemo.BoltDBboltDB =Boltmobiledemo.NewBoltDB(path)

- (void)demo {NSString* path = [NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,                                                          NSUserDomainMask,YES)objectAtIndex:0];GoBoltmobiledemoBoltDB * demo =GoBoltmobiledemoNewBoltDB(path);[selfaddSkipBackupAttributeToItemAtPath:demo.path];//Some DB Logic would go here[democlose];}- (BOOL)addSkipBackupAttributeToItemAtPath:(NSString *) filePathString{NSURL* URL= [NSURLfileURLWithPath: filePathString];assert([[NSFileManagerdefaultManager]fileExistsAtPath: [URLpath]]);NSError *error =nil;BOOL success = [URLsetResourceValue: [NSNumbernumberWithBool:YES]forKey:NSURLIsExcludedFromBackupKeyerror: &error];if(!success){NSLog(@"Error excluding%@ from backup%@", [URLlastPathComponent], error);    }return success;}

For more information on getting started with Bolt, check out the following articles:

• Intro to BoltDB: Painless Performant Persistence byNate Finch.
• Bolt -- an embedded key/value database for Go by Progville

Relational databases structure data into rows and are only accessible throughthe use of SQL. This approach provides flexibility in how you store and queryyour data but also incurs overhead in parsing and planning SQL statements. Boltaccesses all data by a byte slice key. This makes Bolt fast to read and writedata by key but provides no built-in support for joining values together.

Most relational databases (with the exception of SQLite) are standalone serversthat run separately from your application. This gives your systemsflexibility to connect multiple application servers to a single databaseserver but also adds overhead in serializing and transporting data over thenetwork. Bolt runs as a library included in your application so all data accesshas to go through your application's process. This brings data closer to yourapplication but limits multi-process access to the data.

LevelDB and its derivatives (RocksDB, HyperLevelDB) are similar to Bolt in thatthey are libraries bundled into the application, however, their underlyingstructure is a log-structured merge-tree (LSM tree). An LSM tree optimizesrandom writes by using a write ahead log and multi-tiered, sorted files calledSSTables. Bolt uses a B+tree internally and only a single file. Both approacheshave trade-offs.

If you require a high random write throughput (>10,000 w/sec) or you need to usespinning disks then LevelDB could be a good choice. If your application isread-heavy or does a lot of range scans then Bolt could be a good choice.

One other important consideration is that LevelDB does not have transactions.It supports batch writing of key/values pairs and it supports read snapshotsbut it will not give you the ability to do a compare-and-swap operation safely.Bolt supports fully serializable ACID transactions.

Bolt was originally a port of LMDB so it is architecturally similar. Both usea B+tree, have ACID semantics with fully serializable transactions, and supportlock-free MVCC using a single writer and multiple readers.

The two projects have somewhat diverged. LMDB heavily focuses on raw performancewhile Bolt has focused on simplicity and ease of use. For example, LMDB allowsseveral unsafe actions such as direct writes for the sake of performance. Boltopts to disallow actions which can leave the database in a corrupted state. Theonly exception to this in Bolt isDB.NoSync.

There are also a few differences in API. LMDB requires a maximum mmap size whenopening anmdb_env whereas Bolt will handle incremental mmap resizingautomatically. LMDB overloads the getter and setter functions with multipleflags whereas Bolt splits these specialized cases into their own functions.

It's important to pick the right tool for the job and Bolt is no exception.Here are a few things to note when evaluating and using Bolt:

• Bolt is good for read intensive workloads. Sequential write performance isalso fast but random writes can be slow. You can useDB.Batch() or add awrite-ahead log to help mitigate this issue.

• Bolt uses a B+tree internally so there can be a lot of random page access.SSDs provide a significant performance boost over spinning disks.

• Try to avoid long running read transactions. Bolt uses copy-on-write soold pages cannot be reclaimed while an old transaction is using them.

• Byte slices returned from Bolt are only valid during a transaction. Once thetransaction has been committed or rolled back then the memory they point tocan be reused by a new page or can be unmapped from virtual memory and you'llsee anunexpected fault address panic when accessing it.

• Bolt uses an exclusive write lock on the database file so it cannot beshared by multiple processes.

• Be careful when usingBucket.FillPercent. Setting a high fill percent forbuckets that have random inserts will cause your database to have very poorpage utilization.

• Use larger buckets in general. Smaller buckets causes poor page utilizationonce they become larger than the page size (typically 4KB).

• Bulk loading a lot of random writes into a new bucket can be slow as thepage will not split until the transaction is committed. Randomly insertingmore than 100,000 key/value pairs into a single new bucket in a singletransaction is not advised.

• Bolt uses a memory-mapped file so the underlying operating system handles thecaching of the data. Typically, the OS will cache as much of the file as itcan in memory and will release memory as needed to other processes. This meansthat Bolt can show very high memory usage when working with large databases.However, this is expected and the OS will release memory as needed. Bolt canhandle databases much larger than the available physical RAM, provided itsmemory-map fits in the process virtual address space. It may be problematicon 32-bits systems.

• The data structures in the Bolt database are memory mapped so the data filewill be endian specific. This means that you cannot copy a Bolt file from alittle endian machine to a big endian machine and have it work. For mostusers this is not a concern since most modern CPUs are little endian.

• Because of the way pages are laid out on disk, Bolt cannot truncate data filesand return free pages back to the disk. Instead, Bolt maintains a free listof unused pages within its data file. These free pages can be reused by latertransactions. This works well for many use cases as databases generally tendto grow. However, it's important to note that deleting large chunks of datawill not allow you to reclaim that space on disk.

• Removing key/values pairs in a bucket during iteration on the bucket usingcursor may not work properly. Each time when removing a key/value pair, thecursor may automatically move to the next position if present. When userscallc.Next() after removing a key, it may skip one key/value pair.Refer to#611 for more detailed info.

  For more information on page allocation,see this comment.

Bolt is a relatively small code base (<5KLOC) for an embedded, serializable,transactional key/value database so it can be a good starting point for peopleinterested in how databases work.

The best places to start are the main entry points into Bolt:

• Open() - Initializes the reference to the database. It's responsible forcreating the database if it doesn't exist, obtaining an exclusive lock on thefile, reading the meta pages, & memory-mapping the file.

• DB.Begin() - Starts a read-only or read-write transaction depending on thevalue of thewritable argument. This requires briefly obtaining the "meta"lock to keep track of open transactions. Only one read-write transaction canexist at a time so the "rwlock" is acquired during the life of a read-writetransaction.

• Bucket.Put() - Writes a key/value pair into a bucket. After validating thearguments, a cursor is used to traverse the B+tree to the page and positionwhere the key & value will be written. Once the position is found, the bucketmaterializes the underlying page and the page's parent pages into memory as"nodes". These nodes are where mutations occur during read-write transactions.These changes get flushed to disk during commit.

• Bucket.Get() - Retrieves a key/value pair from a bucket. This uses a cursorto move to the page & position of a key/value pair. During a read-onlytransaction, the key and value data is returned as a direct reference to theunderlying mmap file so there's no allocation overhead. For read-writetransactions, this data may reference the mmap file or one of the in-memorynode values.

• Cursor - This object is simply for traversing the B+tree of on-disk pagesor in-memory nodes. It can seek to a specific key, move to the first or lastvalue, or it can move forward or backward. The cursor handles the movement upand down the B+tree transparently to the end user.

• Tx.Commit() - Converts the in-memory dirty nodes and the list of free pagesinto pages to be written to disk. Writing to disk then occurs in two phases.First, the dirty pages are written to disk and anfsync() occurs. Second, anew meta page with an incremented transaction ID is written and anotherfsync() occurs. This two phase write ensures that partially written datapages are ignored in the event of a crash since the meta page pointing to themis never written. Partially written meta pages are invalidated because theyare written with a checksum.

If you have additional notes that could be helpful for others, please submitthem via pull request.

• bbolt might run into data corruption issue on Linux when the featureext4: fast commit, which was introduced inlinux kernel version v5.10, is enabled. The fixes to the issue were included inlinux kernel version v5.17, please refer to links below,

  • ext4: fast commit may miss tracking unwritten range during ftruncate
  • ext4: fast commit may not fallback for ineligible commit
  • ext4 updates for 5.17

  Please also refer to the discussion in#562.

• Writing a value with a length of 0 will always result in reading back an empty[]byte{} value.Please refer toissues/726#issuecomment-2061694802.

Below is a list of public, open source projects that use Bolt:

• Algernon - A HTTP/2 web server with built-in support for Lua. Uses BoltDB as the default database backend.
• Bazil - A file system that lets your data reside where it is most convenient for it to reside.
• bolter - Command-line app for viewing BoltDB file in your terminal.
• boltcli - the redis-cli for boltdb with Lua script support.
• BoltHold - An embeddable NoSQL store for Go types built on BoltDB
• BoltStore - Session store using Bolt.
• Boltdb Boilerplate - Boilerplate wrapper around bolt aiming to make simple calls one-liners.
• BoltDbWeb - A web based GUI for BoltDB files.
• BoltDB Viewer - A BoltDB Viewer Can run on Windows、Linux、Android system.
• bleve - A pure Go search engine similar to ElasticSearch that uses Bolt as the default storage backend.
• bstore - Database library storing Go values, with referential/unique/nonzero constraints, indices, automatic schema management with struct tags, and a query API.
• btcwallet - A bitcoin wallet.
• buckets - a bolt wrapper streamliningsimple tx and key scans.
• Buildkit - concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit
• cayley - Cayley is an open-source graph database using Bolt as optional backend.
• ChainStore - Simple key-value interface to a variety of storage engines organized as a chain of operations.
• 🌰 Chestnut - Chestnut is encrypted storage for Go.
• Consul - Consul is service discovery and configuration made easy. Distributed, highly available, and datacenter-aware.
• Containerd - An open and reliable container runtime
• DVID - Added Bolt as optional storage engine and testing it against Basho-tuned leveldb.
• dcrwallet - A wallet for the Decred cryptocurrency.
• drive - drive is an unofficial Google Drive command line client for *NIX operating systems.
• event-shuttle - A Unix system service to collect and reliably deliver messages to Kafka.
• Freehold - An open, secure, and lightweight platform for your files and data.
• Go Report Card - Go code quality report cards as a (free and open source) service.
• GoWebApp - A basic MVC web application in Go using BoltDB.
• GoShort - GoShort is a URL shortener written in Golang and BoltDB for persistent key/value storage and for routing it's using high performent HTTPRouter.
• gopherpit - A web service to manage Go remote import paths with custom domains
• gokv - Simple key-value store abstraction and implementations for Go (Redis, Consul, etcd, bbolt, BadgerDB, LevelDB, Memcached, DynamoDB, S3, PostgreSQL, MongoDB, CockroachDB and many more)
• Gitchain - Decentralized, peer-to-peer Git repositories aka "Git meets Bitcoin".
• InfluxDB - Scalable datastore for metrics, events, and real-time analytics.
• ipLocator - A fast ip-geo-location-server using bolt with bloom filters.
• ipxed - Web interface and api for ipxed.
• Ironsmith - A simple, script-driven continuous integration (build - > test -> release) tool, with no external dependencies
• Kala - Kala is a modern job scheduler optimized to run on a single node. It is persistent, JSON over HTTP API, ISO 8601 duration notation, and dependent jobs.
• Key Value Access Language (KVAL) - A proposed grammar for key-value datastores offering a bbolt binding.
• LedisDB - A high performance NoSQL, using Bolt as optional storage.
• lru - Easy to use Bolt-backed Least-Recently-Used (LRU) read-through cache with chainable remote stores.
• mbuckets - A Bolt wrapper that allows easy operations on multi level (nested) buckets.
• MetricBase - Single-binary version of Graphite.
• MuLiFS - Music Library Filesystem creates a filesystem to organise your music files.
• NATS - NATS Streaming uses bbolt for message and metadata storage.
• Portainer - A lightweight service delivery platform for containerized applications that can be used to manage Docker, Swarm, Kubernetes and ACI environments.
• Prometheus Annotation Server - Annotation server for PromDash & Prometheus service monitoring system.
• Rain - BitTorrent client and library.
• reef-pi - reef-pi is an award winning, modular, DIY reef tank controller using easy to learn electronics based on a Raspberry Pi.
• Request Baskets - A web service to collect arbitrary HTTP requests and inspect them via REST API or simple web UI, similar toRequestBin service
• Seaweed File System - Highly scalable distributed key~file system with O(1) disk read.
• stow - a persistence manager for objectsbacked by boltdb.
• Storm - Simple and powerful ORM for BoltDB.
• SimpleBolt - A simple way to use BoltDB. Deals mainly with strings.
• Skybox Analytics - A standalone funnel analysis tool for web analytics.
• Scuttlebutt - Uses Bolt to store and process all Twitter mentions of GitHub projects.
• tentacool - REST api server to manage system stuff (IP, DNS, Gateway...) on a linux server.
• torrent - Full-featured BitTorrent client package and utilities in Go. BoltDB is a storage backend in development.
• Wiki - A tiny wiki using Goji, BoltDB and Blackfriday.

If you are using Bolt in a project please send a pull request to add it to the list.