I built *snkvDB* — a single-header, ACID-compliant key-value store with zero setup.
https://github.com/hash-anu/snkv
### Why I built this
I wanted something as simple as a hashmap, but:
* persistent
* crash-safe
* no external dependencies
* easy to drop into any C/C++ project
Most KV stores are either:
* too heavy (servers, background processes), or
* too low-level (you manage everything)
snkvDB tries to sit in between.
---
### What it is
* Single-header KV store (just include and use)
* ACID compliant (thanks to SQLite)
* No server, no config, no build system required
* Works like a simple embedded database
---
### Under the hood
snkvDB is built on SQLite’s storage engine (B-Tree backend), so you get:
* durability
* transactions
* mature, battle-tested storage
But the API is simplified to a minimal KV interface.
---
### When to use it
* Embedding storage in CLI tools or small apps
* Replacing ad-hoc file storage
* Lightweight persistence without running a DB server
---
### Benchmarks
I’ve compared it with RocksDB and LMDB here:
https://github.com/hash-anu/snkv
TL;DR:
* Faster than RocksDB for small/medium workloads
* Easier to use than LMDB
* Balanced read/write performance
---
### Trade-offs
* Not for write-heavy, high-throughput workloads (RocksDB is better there)
* LMDB can be faster for pure reads
* This prioritizes simplicity + safety over raw performance
---
Would love feedback, especially on:
* API design
* performance
* real-world use cases
This is not just a thin wrapper over SQLite.
The goal was to build a *minimal KV interface* (put/get/delete) that feels like a hashmap, while delegating durability + ACID guarantees to SQLite underneath.
So you don’t deal with:
* SQL * schema design * connection management
Just a simple embedded KV store in a single header.
Also happy to explain design decisions or internals if anyone’s curious
reply