Sign inDemoInstall

Package Overview
File Explorer

Install Socket

Protect your apps from supply chain attacks


Package badger implements an embeddable, simple and fast key-value database, written in pure Go. It is designed to be highly performant for both reads and writes simultaneously. Badger uses Multi-Version Concurrency Control (MVCC), and supports transactions. It runs transactions concurrently, with serializable snapshot isolation guarantees. Badger uses an LSM tree along with a value log to separate keys from values, hence reducing both write amplification and the size of the LSM tree. This allows LSM tree to be served entirely from RAM, while the values are served from SSD. Badger has the following main types: DB, Txn, Item and Iterator. DB contains keys that are associated with values. It must be opened with the appropriate options before it can be accessed. All operations happen inside a Txn. Txn represents a transaction, which can be read-only or read-write. Read-only transactions can read values for a given key (which are returned inside an Item), or iterate over a set of key-value pairs using an Iterator (which are returned as Item type values as well). Read-write transactions can also update and delete keys from the DB. See the examples for more usage details.


Version published


# BadgerDB 

[![Go Reference](]( 
[![Go Report Card](]( 

![Badger mascot](images/diggy-shadow.png)

BadgerDB is an embeddable, persistent and fast key-value (KV) database written
in pure Go. It is the underlying database for [Dgraph](, a
fast, distributed graph database. It's meant to be a performant alternative to
non-Go-based key-value stores like RocksDB.

## Project Status

Badger is stable and is being used to serve data sets worth hundreds of
terabytes. Badger supports concurrent ACID transactions with serializable
snapshot isolation (SSI) guarantees. A Jepsen-style bank test runs nightly for
8h, with `--race` flag and ensures the maintenance of transactional guarantees.
Badger has also been tested to work with filesystem level anomalies, to ensure
persistence and consistency. Badger is being used by a number of projects which
includes Dgraph, Jaeger Tracing, UsenetExpress, and many more.

The list of projects using Badger can be found [here](#projects-using-badger).

Badger v1.0 was released in Nov 2017, and the latest version that is data-compatible
with v1.0 is v1.6.0.

Badger v2.0 was released in Nov 2019 with a new storage format which won't
be compatible with all of the v1.x. Badger v2.0 supports compression, encryption and uses a cache to speed up lookup.

Badger v3.0 was released in January 2021.  This release improves compaction performance.

Please consult the [Changelog] for more detailed information on releases.

For more details on our version naming schema please read [Choosing a version](#choosing-a-version).


## Table of Contents
 * [Getting Started](#getting-started)
    + [Installing](#installing)
      - [Installing Badger Command Line Tool](#installing-badger-command-line-tool)
      - [Choosing a version](#choosing-a-version)
  * [Badger Documentation](#badger-documentation)
  * [Resources](#resources)
    + [Blog Posts](#blog-posts)
  * [Design](#design)
    + [Comparisons](#comparisons)
    + [Benchmarks](#benchmarks)
  * [Projects Using Badger](#projects-using-badger)
  * [Contributing](#contributing)
  * [Contact](#contact)

## Getting Started

### Installing
To start using Badger, install Go 1.12 or above. Badger v3 needs go modules. From your project, run the following command

$ go get
This will retrieve the library.

#### Installing Badger Command Line Tool

Badger provides a CLI tool which can perform certain operations like offline backup/restore.  To install the Badger CLI, 
retrieve the repository and checkout the desired version.  Then run

$ cd badger
$ go install .
This will install the badger command line utility into your $GOBIN path. 

#### Choosing a version

BadgerDB is a pretty special package from the point of view that the most important change we can
make to it is not on its API but rather on how data is stored on disk.

This is why we follow a version naming schema that differs from Semantic Versioning.

- New major versions are released when the data format on disk changes in an incompatible way.
- New minor versions are released whenever the API changes but data compatibility is maintained.
 Note that the changes on the API could be backward-incompatible - unlike Semantic Versioning.
- New patch versions are released when there's no changes to the data format nor the API.

Following these rules:

- v1.5.0 and v1.6.0 can be used on top of the same files without any concerns, as their major
 version is the same, therefore the data format on disk is compatible.
- v1.6.0 and v2.0.0 are data incompatible as their major version implies, so files created with
 v1.6.0 will need to be converted into the new format before they can be used by v2.0.0.
 - v2.x.x and v3.x.x are data incompatible as their major version implies, so files created with
 v2.x.x will need to be converted into the new format before they can be used by v3.0.0.

For a longer explanation on the reasons behind using a new versioning naming schema, you can read

## Badger Documentation

Badger Documentation is available at

## Resources

### Blog Posts
1. [Introducing Badger: A fast key-value store written natively in
2. [Make Badger crash resilient with ALICE](
3. [Badger vs LMDB vs BoltDB: Benchmarking key-value databases in Go](
4. [Concurrent ACID Transactions in Badger](

## Design
Badger was written with these design goals in mind:

- Write a key-value database in pure Go.
- Use latest research to build the fastest KV database for data sets spanning terabytes.
- Optimize for SSDs.

Badger’s design is based on a paper titled _[WiscKey: Separating Keys from
Values in SSD-conscious Storage][wisckey]_.


### Comparisons
| Feature                        | Badger                                     | RocksDB                       | BoltDB    |
| -------                        | ------                                     | -------                       | ------    |
| Design                         | LSM tree with value log                    | LSM tree only                 | B+ tree   |
| High Read throughput           | Yes                                        | No                            | Yes       |
| High Write throughput          | Yes                                        | Yes                           | No        |
| Designed for SSDs              | Yes (with latest research <sup>1</sup>)    | Not specifically <sup>2</sup> | No        |
| Embeddable                     | Yes                                        | Yes                           | Yes       |
| Sorted KV access               | Yes                                        | Yes                           | Yes       |
| Pure Go (no Cgo)               | Yes                                        | No                            | Yes       |
| Transactions                   | Yes, ACID, concurrent with SSI<sup>3</sup> | Yes (but non-ACID)            | Yes, ACID |
| Snapshots                      | Yes                                        | Yes                           | Yes       |
| TTL support                    | Yes                                        | Yes                           | No        |
| 3D access (key-value-version)  | Yes<sup>4</sup>                            | No                            | No        |

<sup>1</sup> The [WISCKEY paper][wisckey] (on which Badger is based) saw big
wins with separating values from keys, significantly reducing the write
amplification compared to a typical LSM tree.

<sup>2</sup> RocksDB is an SSD optimized version of LevelDB, which was designed specifically for rotating disks.
As such RocksDB's design isn't aimed at SSDs.

<sup>3</sup> SSI: Serializable Snapshot Isolation. For more details, see the blog post [Concurrent ACID Transactions in Badger](

<sup>4</sup> Badger provides direct access to value versions via its Iterator API.
Users can also specify how many versions to keep per key via Options.

### Benchmarks
We have run comprehensive benchmarks against RocksDB, Bolt and LMDB. The
benchmarking code, and the detailed logs for the benchmarks can be found in the
[badger-bench] repo. More explanation, including graphs can be found the blog posts (linked


## Projects Using Badger
Below is a list of known projects that use Badger:

* [Dgraph]( - Distributed graph database.
* [Jaeger]( - Distributed tracing platform.
* [go-ipfs]( - Go client for the InterPlanetary File System (IPFS), a new hypermedia distribution protocol.
* [Riot]( - An open-source, distributed search engine.
* [emitter]( - Scalable, low latency, distributed pub/sub broker with message storage, uses MQTT, gossip and badger.
* [OctoSQL]( - Query tool that allows you to join, analyse and transform data from multiple databases using SQL.
* [Dkron]( - Distributed, fault tolerant job scheduling system.
* [smallstep/certificates]( - Step-ca is an online certificate authority for secure, automated certificate management.
* [Sandglass]( - distributed, horizontally scalable, persistent, time sorted message queue.
* [TalariaDB]( - Grab's Distributed, low latency time-series database.
* [Sloop]( - Salesforce's Kubernetes History Visualization Project.
* [Immudb]( - Lightweight, high-speed immutable database for systems and applications.
* [Usenet Express]( - Serving over 300TB of data with Badger.
* [gorush]( - A push notification server written in Go.
* [0-stor]( - Single device object store.
* [Dispatch Protocol]( - Blockchain protocol for distributed application data analytics.
* [GarageMQ]( - AMQP server written in Go.
* [RedixDB]( - A real-time persistent key-value store with the same redis protocol.
* [BBVA]( - Raft backend implementation using BadgerDB for Hashicorp raft.
* [Fantom]( - aBFT Consensus platform for distributed applications.
* [decred]( - An open, progressive, and self-funding cryptocurrency with a system of community-based governance integrated into its blockchain.
* [OpenNetSys]( - Create useful dApps in any software language.
* [HoneyTrap]( - An extensible and opensource system for running, monitoring and managing honeypots.
* [Insolar]( - Enterprise-ready blockchain platform.
* [IoTeX]( - The next generation of the decentralized network for IoT powered by scalability- and privacy-centric blockchains.
* [go-sessions]( - The sessions manager for Go net/http and fasthttp.
* [Babble]( - BFT Consensus platform for distributed applications.
* [Tormenta]( - Embedded object-persistence layer / simple JSON database for Go projects.
* [BadgerHold]( - An embeddable NoSQL store for querying Go types built on Badger
* [Goblero]( - Pure Go embedded persistent job queue backed by BadgerDB
* [Surfline]( - Serving global wave and weather forecast data with Badger.
* [Cete]( - Simple and highly available distributed key-value store built on Badger. Makes it easy bringing up a cluster of Badger with Raft consensus algorithm by hashicorp/raft. 
* [Volument]( - A new take on website analytics backed by Badger.
* [KVdb]( - Hosted key-value store and serverless platform built on top of Badger.
* [Terminotes]( - Self hosted notes storage and search server - storage powered by BadgerDB
* [Pyroscope]( - Open source confinuous profiling platform built with BadgerDB
* [Veri]( - A distributed feature store optimized for Search and Recommendation tasks.
* [bIter]( - A library and Iterator interface for working with the `badger.Iterator`, simplifying from-to, and prefix mechanics.
* [ld]( - (Lean Database) A very simple gRPC-only key-value database, exposing BadgerDB with key-range scanning semantics.
* [Souin]( - A RFC compliant HTTP cache with lot of other features based on Badger for the storage. Compatible with all existing reverse-proxies.
* [Xuperchain]( - A highly flexible blockchain architecture with great transaction performance.
* [m2]( - A simple http key/value store based on the raft protocol.
* [chaindb]( - A blockchain storage layer used by [Gossamer](, a Go client for the [Polkadot Network](
* [vxdb]( - Simple schema-less Key-Value NoSQL database with simplest API interface.
* [Opacity]( - Backend implementation for the Opacity storage project
* [Vephar]( - A minimal key/value store using hashicorp-raft for cluster coordination and Badger for data storage.

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

## Contributing

If you're interested in contributing to Badger see [CONTRIBUTING](./

## Contact
- Please use []( for questions, feature requests and discussions.
- Please use []( for filing bugs or feature requests.
- Follow us on Twitter [@dgraphlabs](


Last updated on 15 Dec 2022

Did you know?

Socket installs a GitHub app to automatically flag issues on every pull request and report the health of your dependencies. Find out what is inside your node modules and prevent malicious activity before you update the dependencies.


Related posts

SocketSocket SOC 2 Logo


  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap

Stay in touch

Get open source security insights delivered straight into your inbox.

  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc