SNKV
SQLite's B-tree as a key-value store (C/C++ and Python bindings)
Details
- External ID
- 47136553
- Source
- HN
- Company
- —
- Product
- SNKV
- Website domain
- github.com
- Launched
- Feb. 24, 2026
- Cohort
- —
- Upvotes
- 36
- Upvotes percentile
- 0.7688679245283019
- Tags
- —
- Fetched at
- Sept. 7, 2026, 9:25 p.m.
- Updated at
- Sept. 7, 2026, 9:25 p.m.
Description
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.
Enrichment
- Theme
- database infrastructure and developer tools
- Vertical
- —
- Function
- Data infrastructure
- Audience
- Developer
- AI stance
- Not AI
- Project type
- Commercial product
- Normalized one-liner
- sqlite b-tree as a key-value store
- Manually corrected
- False
Could you build this?
No It requires low-level C programming directly interfacing with SQLite's internal non-public B-tree and pager subsystem headers, bypassing public APIs.
What it would actually take: Building this requires intimate understanding of SQLite's C internal architecture (btree.c, pager.c, wal.c), memory allocation flags, and internal transaction control blocks. Developers must maintain binary compatibility with SQLite's internal data structures, write custom C/C++ bindings, and ensure memory safety and zero corruption without SQLite's safety wrappers.
Discussion
20 comments analyzed.
Competitors mentioned: RocksDB, Berkeley DB, dbm/gdbm, LiteFS, lite3
Concerns raised: Project flagged for spam/repeated reposts across multiple accounts, Code and documentation allegedly AI-generated rather than authored, Benchmark fairness questioned regarding sqlite3_exec usage, Credibility damaged by inconsistent response styles in comments, Legitimacy of performance claims against established alternatives
Feature requests: Performance comparison: multiple trees in single file vs. one tree per file
Competitors
Other products that read as similar to this one — 84 launches clear the similarity bar, closest 8 shown.
Attention rank: #25 of 85 (itself plus its competitors, highest first — normalized so YC and Product Hunt are compared fairly).
Launched 118 days after the earliest competitor.
- SnkvDB · hn · 2026-02-16 · 5 upvotes · similarity 0.73
- Turbolite · hn · 2026-03-26 · 185 upvotes · similarity 0.53
- Sqlit · hn · 2025-12-15 · 190 upvotes · similarity 0.43
- Llm.sql · hn · 2026-04-24 · 8 upvotes · similarity 0.43
- UseSQLite · ph · 2026-09-16 · 2 upvotes · similarity 0.41
- Capsule · hn · 2026-09-15 · 377 upvotes · similarity 0.41
- SQLite for Rivet Actors · hn · 2026-02-28 · 45 upvotes · similarity 0.41
- ChikkaDB · hn · 2025-11-29 · 5 upvotes · similarity 0.41
Other launches for this product
- No other launches for this product.