#key-value-database #sqlite #robust #built #sql #reasonably

boringdb

Robust, reasonably high-performance key-value database built on SQLite

20 releases

0.4.1 May 12, 2022
0.3.15 May 9, 2022
0.3.14 Jan 18, 2022
0.3.13 Dec 8, 2021
0.3.10 Jul 8, 2021

#2309 in Database interfaces


Used in 2 crates

ISC license

16KB
269 lines

BoringDB

A SQLite-based, single-process, key-value database.

You want boringdb if:

  • You want high performance somewhat approaching that of databases like sled and RocksDB
  • You don't need SQL, multiprocess support, or the other cool features of SQLite
  • You want SQLite's proven reliability

Method Of Operation

BoringDB stores key/value pairs into byte vectors (Vec<u8>).

Examples

We have various usage examples here.

To run any of the examples, execute:

cargo run --example example_name_goes_here

Cache architecture

We have a writeback cache supporting the following operations:

  • Insert with batch number
  • Read key with fallback closure
  • Remove dirty keys as an iterator-like object that returns batches.

lib.rs:

BoringDB

A SQLite-based, single-process, key-value database.

You want boringdb if:

  • You want high performance somewhat approaching that of databases like sled and RocksDB
  • You don't need SQL, multiprocess support, or the other cool features of SQLite
  • You want SQLite's proven reliability

A note on durability

By default, boringdb has eventual durability: database state is guaranteed to be consistent even in the face of arbitrary crashes, and transactions are guaranteed to have "serializable" semantics. However, after a crash the database may be slightly out of date, usually by a fraction of a second.

To avoid this behavior, use the Dict::flush method to manually force synchronization with disk. Note that this comes with a fairly severe performance cost.

Method Of Operation

BoringDB stores key/value pairs into byte vectors (Vec<u8>).

Examples

Examples can be found in the examples directory

Dependencies

~24MB
~459K SLoC