HN Explorer

Show HN: SNKV – SQLite's B-tree as a key-value store (C/C++ and Python bindings) (github.com)

36 points by swaminarayan ↗ HN
SQLite has six layers: SQL parser → query planner → VDBE → B-tree → pager → OS. (https://sqlite.org/arch.html) For key-value workloads you only need the bottom three.

SNKV cuts the top three layers and talks directly to SQLite's B-tree engine. No SQL strings. No query planner. No VM. Just put/get/delete on the same storage core that powers SQLite.

Python:

    pip install snkv

    from snkv import KVStore

    with KVStore("mydb.db") as db:
        db["hello"] = "world"
        print(db["hello"])   # b"world"
C/C++ (single-header, drop-in):

    #define SNKV_IMPLEMENTATION
    #include "snkv.h"

    KVStore *db;
    kvstore_open("mydb.db", &db, KVSTORE_JOURNAL_WAL);
    kvstore_put(db, "key", 3, "value", 5);
Benchmarks vs SQLite WITHOUT ROWID (1M records, identical settings):

  Sequential writes  +57%
  Random reads       +68%
  Sequential scan    +90%
  Random updates     +72%
  Random deletes    +104%
  Exists checks      +75%
  Mixed workload     +84%
  Bulk insert        +10%
Honest tradeoffs: - LMDB beats it on raw reads (memory-mapped) - RocksDB beats it on write-heavy workloads (LSM-tree) - sqlite3 CLI won't open the database (schema layer is bypassed by design)

What you get: ACID, WAL concurrency, column families, crash safety — with less overhead for read-heavy KV workloads.

7 comments

[ 3.4 ms ] story [ 38.1 ms ] thread
Retr0id
I'm surprised by your benchmark results.

I've considered building this exact thing before (I think I've talked about it on HN even), but the reason I didn't build it was because I was sure (on an intuitive level) the actual overhead of the SQL layer was negligible for simple k/v queries.

Where does the +104% on random deletes (for example) actually come from?

m00dy
I did the same on rust, sqlite btree behind actix. It is amazing that you don't need redis anymore.
rurban
It doesn't beat a hashtable, but has faster sequential (=ordered) reads, and can do range iterators. The examples to not reflect that.

All random accesses are slower.

d1l
Vibe coded trash.

that credulous hn readers will upvote this is alarming.

franticgecko3
OP seems to self promote this project and other similar vibe coded works every few weeks under two different HN handles.

Edit: for me this post appears on the front page of HN. OP this is mission success - add this project to your résumé and stop spamming.

ThrowawayR2
Nine reposts across the last 21 days across a couple of fresh accounts, some of which seem to be banned(?).

- Show HN: SNKV – KV store on SQLite's B-tree with 11x less memory than RocksDB (github.com/hash-anu) 3 points by swaminarayan 6 days ago

- I read 150K lines of SQLite source — here’s how its B-Tree powers a KV store (github.com/hash-anu) 1 point by hashmakjsn 6 days ago | 1 comment

- Show HN: SnkvDB – Single-header ACID KV store using SQLite's B-Tree engine (github.com/hash-anu) 5 points by hashmakjsn 8 days ago | 1 comment

- Show HN: SNKV benchmark with RocksDB (github.com/hash-anu) 2 points by hashmakjsn 13 days ago

- Show HN: SNKV and LiteFS – Distributed KV store with automatic replication (github.com/hash-anu) 3 points by hashmakjsn 14 days ago

- Show HN: In SQLite v3.51.2 skipped query layers and accessed b-tree APIs for KV 1 point by hashmak_jsn 15 days ago

- Show HN: Developed key value storage using SQLite's b-tree APIs directly (github.com/hash-anu) 4 points by hashmakjsn 15 days ago

- Show HN: Developed key value storage using SQLite b-tree APIs directly (github.com/hash-anu) 1 point by hashmak_jsn 20 days ago

- Show HN: SNKV — A Key-Value Store Built Directly on SQLite’s B-Tree APIs (github.com/hash-anu) 1 point by hashmak_jsn 21 days ago