Back to browse
GitHub Repository

SNKV — a lightweight key-value store focused on simplicity, security and performance file based database , written using b-tree directly. Now supports vector HNSW , Join the discussion: https://discord.gg/EUb4Y5qE

76 starsC

SnkvDB – Single-header ACID KV store using SQLite's B-Tree engine

by hashmakjsn·Feb 16, 2026·5 points·1 comment

AI Analysis

●●SolidNiche GemWizardrySolve My Problem

SQLite's proven storage minus SQL parsing—3–5× throughput for KV-only workloads.

Strengths
  • Genuinely removes SQL overhead (parser, planner, VDBE) while keeping durable B-Tree core
  • Single-header integration with zero dependencies makes drop-in adoption frictionless
  • Comprehensive benchmarks (valgrind, tests, memory profiling) prove claimed performance gains
Weaknesses
  • Niche audience: C/C++ embedded projects; no language bindings announced yet
  • ACID guarantees inherited from SQLite but transaction API not deeply documented
Target Audience

C/C++ developers needing persistent, crash-safe KV storage without server overhead

Similar To

RocksDB · LevelDB · SQLite native API

Post Description

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

Similar Projects