Badger started as a key-value store, so the goal was to use the latest research to build the fastest key-value store. It uses a log-structured merge (LSM) tree based implementation, which has the advantage of higher throughput when compared to B+ tree since background (disk) writes in LSM maintain a sequential access pattern.
BadgerDB was initially a persistent key-value store intended to replace DgraphDB’s dependency on RockDB, since RockDB is written in C++ and requires the use of Cgo to be called via Go. It was a (side) project lead by Manish Rai Jain, a chief decision maker at Dgraph, and as the project progressed, it upgraded from being a key-value store to a database system.
BadgerDB supports a LSM tree, where keys are stored in the LSM and values are store in a write-ahead log called a value log. Since key tend to be smaller than values, this allows the system to maintain a smaller LSM tree. To allow efficient access, the LSM make sure to maintain a sorted order, making range queries easier to process, as well.
The query interface for BadgerDB is in Go since the system was originally created to provide a good key-value store that can easily be accessed through Go without having to go through Ggo.
BadgerDB uses delta encoding to reduce the size of keys, to further reduce the size of the LSMs. Also, during a read, a fingerprint of the key is stored rather than the key itself to also save space.
I do not think BadgerDB supports views.
Badger supports ACID transactions and Multi-Version Concurrency Control with Snapshot Isolation. Badger acquires locks on directories when accessing data, so multiple processes cannot open the same database at the same time.
Badger’s underlying functionality is an efficient key-value store.
I do not think BadgerDB supports stored procedures.
BadgerDB supports snapshot isolation. Badger also has read-only transactions (called Views), that ensures a consistent view of the database system, and that will not include changes made by an uncommitted transaction at the start of this transactions. With read-write transactions, if a conflict occurs, the transaction will written with an error notifying the user of a conflict, giving the user the option to retry the transaction.