Nicheloom

Market intelligence for builders — see what's gaining traction before it's crowded.

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.

Other launches for this product