hash-anu

snkv

C2026–2026

hash-anu / snkv

snkv

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

Explore on GitHub Read Hacker News discussions

3Distinct people

17Mentions

0Explicit recommenders

80GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by week17 dated mentions

Observed mentions: 2026-02-09 11:17:44 UTC to 2026-05-10 08:46:59 UTC. Weeks start Monday, UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
Feb 9	2026-02-09 00:00:00 UTC	2026-02-16 00:00:00 UTC	3	3	0
Feb 16	2026-02-16 00:00:00 UTC	2026-02-23 00:00:00 UTC	4	3	1
Feb 23	2026-02-23 00:00:00 UTC	2026-03-02 00:00:00 UTC	4	2	2
Mar 2	2026-03-02 00:00:00 UTC	2026-03-09 00:00:00 UTC	0	0	0
Mar 9	2026-03-09 00:00:00 UTC	2026-03-16 00:00:00 UTC	0	0	0
Mar 16	2026-03-16 00:00:00 UTC	2026-03-23 00:00:00 UTC	1	0	1
Mar 23	2026-03-23 00:00:00 UTC	2026-03-30 00:00:00 UTC	3	0	3
Mar 30	2026-03-30 00:00:00 UTC	2026-04-06 00:00:00 UTC	1	1	0
Apr 6	2026-04-06 00:00:00 UTC	2026-04-13 00:00:00 UTC	0	0	0
Apr 13	2026-04-13 00:00:00 UTC	2026-04-20 00:00:00 UTC	0	0	0
Apr 20	2026-04-20 00:00:00 UTC	2026-04-27 00:00:00 UTC	0	0	0
Apr 27	2026-04-27 00:00:00 UTC	2026-05-04 00:00:00 UTC	0	0	0
May 4	2026-05-04 00:00:00 UTC	2026-05-11 00:00:00 UTC	1	1	0

What Hacker News says

17 sources

swaminarayan·May 10, 2026Submission

Show HN: Query months of HN discussions and comments as a knowledge graph

I built lightrag-snkv, Basically it uses lightRAG https://github.com/HKUDS/LightRAG ,this requires various storage databases like key value store, graph database, vector database, I built single embedded file based database which covers all these requirements: https://github.com/hash-anu/snkv. And developed ingestor which ingest data from Algolia's HN search API. Here auto ingestion timings can be configured either using server.py or it can be configured by ingester code file or can be configured in env file. This is very early stage and you might hit issues. Demo video and quick-start in the README. Let me know if you run into issues.

4 points · Open discussion

swaminarayan·Apr 3, 2026Submission

Ask HN: Best LLM model for a RAG-based Android app across all smartphones?

I am developing RAG based android app using llama.cpp. For offline processing I am using Qwen 1.5 2.5B model using Q4 quantization, I am offloading computation to GPU if present, However for low end android phones my android app is either crashing due to OOM or If not crashing and no GPU available in that case it takes lots of time to generate text. I also tried with SmolLM 135M model for low end devices but it struggle to follow instruction very well. In this case I am considering openAI API for low end android phones. And for vector storage I am using in house developed https://github.com/hash-anu/snkv, I am not sure how other people are running LLM model on low end android devices, I would appreciate any insights or best practices.

1 points · Open discussion

swaminarayan·Mar 27, 2026

Interesting approach — especially around modifying SQLite’s internals. In SNKV, I’m taking almost the opposite direction: keeping B-tree / storage-layer ideas and removing the SQL layer entirely, to expose a minimal key-value interface. Curious how you think about the tradeoff between simplifying the query layer vs the storage layer. https://github.com/hash-anu/snkv

In DoltLite: Free, open source drop-in replacement for SQLite with version control

swaminarayan·Mar 27, 2026

Really interesting design — especially using SQLite-compatible storage with a PostgreSQL interface. I'm working on SNKV, which explores a different approach: skipping the SQL layer entirely and focusing on a simple key-value interface. It works closer to the storage layer (b-tree / WAL / pager concepts), aiming for a lightweight and minimal design, while supporting multi-process access. Curious how you think about the tradeoff between SQL flexibility and a simpler KV interface. https://github.com/hash-anu/snkv

In In-process reimplementation of PostgreSQL backed by SQLite-compatible storage

swaminarayan·Mar 27, 2026

Very cool approach. I’m working on a related KV storage project (snkv - https://github.com/hash-anu/snkv) How do you handle manifest consistency and updates—append-only or rewrite-heavy?

In Show HN: Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3

swaminarayan·Mar 19, 2026

if you want to use key value store using sqlite then you can try : https://github.com/hash-anu/snkv in which i am directly accessing b-tree layer and not consuming query layer. for kv workloads it is much faster compare to sql. and yeah you will get same benefits of sqlite storage engine.

In Show HN: Pgit – A Git-like CLI backed by PostgreSQL

swaminarayan·Feb 26, 2026Submission

Ask HN: Designing TTL for a B-tree KV store – feedback on dual-index approach

4 points · Open discussion

swaminarayan·Feb 26, 2026

Adding TTL to an embedded KV store (built on SQLite's B-tree layer, not SQL). The constraint: TTL needs two conflicting access patterns – lookup by key (get expiry check) and scan by expiry time (efficient purge). Single index can't serve both. Using two hidden companion CFs to solve this. Three open questions: 1. Transparent expiry on get() vs explicit TTL check – which is better UX? 2. Should purge_expired() accept a max_keys limit to bound transaction size? 3. Seconds vs milliseconds precision – is sub-second TTL ever needed? Design doc: https://github.com/hash-anu/snkv/blob/adding_ttl/docs/propos... For new devs, Current design doc: https://github.com/hash-anu/snkv/blob/adding_ttl/internal/KV...

In Ask HN: Designing TTL for a B-tree KV store – feedback on dual-index approach

swaminarayan·Feb 24, 2026

I am showing examples/ showing demo gif https://github.com/hash-anu/snkv/blob/master/demo.gif. Showing code.

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

swaminarayan·Feb 24, 2026Submission

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

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% Sequenti

Read the rest

al 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.

36 points · Open discussion

swaminarayan·Feb 18, 2026Submission

Show HN: SNKV – KV store on SQLite's B-tree with 11x less memory than RocksDB

While working with RocksDB, I noticed it consumed significantly more memory than expected for small workloads. On a 1M record benchmark, it peaked at ~121 MB RSS. That got me thinking: what if I skip the query layer entirely and use SQLite purely as a storage engine? So I started digging into SQLite internals — specifically the B-tree, pager, and OS layers — to understand how data is actually stored and managed under the hood. I documented what I learned along the way: B-tree operations: https://github.com/hash-anu/snkv/blob/master/internal/BTREE_... Pager operations: https://github.com/hash-anu/snkv/blob/master/internal/PAGER_... OS layer operations: https://github.com/hash-anu/snkv/blob/master/internal/OS_LAY... Once I understood the core pieces, I built a simple key-value store directly on top of SQLite's B-tree layer — reusing its sto

Read the rest

rage management, paging, and file I/O without touching the SQL engine at all. I then added column family support, WAL and journal modes, and transactions. For easier integration, I generated a single amalgamated header (similar to SQLite's approach): https://github.com/hash-anu/snkv Benchmarks (1M records, sync-on-commit enabled for both): RocksDB SNKV Sequential writes: 237K/s 181K/s Random reads: 95K/s 154K/s Sequential scan: 1.78M/s 5.95M/s Mixed workload: 51K/s 97K/s Peak memory (RSS): 121 MB 10.8 MB (~11x less) RocksDB's LSM-tree design gives it a clear write advantage, and with tuning (bloom filters, larger caches) its read numbers would improve too. The memory gap is structural though — RocksDB carries significantly more overhead even when constrained to a small footprint configuration. The full KV layer documentation is here: https://github.com/hash-anu/snkv/blob/master/internal/KVSTOR... Curious if others have hit the same memory wall with RocksDB on small workloads, or taken a different approach to this tradeoff.

3 points · Open discussion

usefulcat·Feb 18, 2026Submission

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

3 points · Open discussion

hashmakjsn·Feb 17, 2026

I’ve been working on a key–value engine built directly on top of SQLite’s storage layer (without SQL). While doing that, I ended up reading ~150K lines of SQLite’s source code to understand how its B-Tree, pager, and storage layers actually work. This write-up focuses on the top-most layer: → how key–value operations map directly onto the B-Tree API Some of the interesting parts: - How inserts/reads bypass SQL and go straight to the B-Tree - Cursor mechanics and traversal - Page-level behavior during reads/writes - Why removing the SQL layer gives significant performance gains If you’re interested in deeper internals (b-tree, pager, WAL, OS layer), I’m planning to share those next. Would love feedback, especially from folks familiar with database internals. Project (SNKV): https://github.com/hash-anu/snkv/tree/master

In [dead]

hashmakjsn·Feb 16, 2026Submission

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

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 *

Read the rest

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

5 points · Open discussion

hashmakjsn·Feb 11, 2026Submission

Show HN: SNKV benchmark with RocksDB

I have been working on SNKV, a lightweight SQLite's B-tree based key value store focused on predictable performance and low memory usage. I benchmarked SNKV against RocksDB using 1,000,000 records on the same hardware with minimal tuning on both sides. Mixed workload 70 percent reads 20 percent writes 10 percent deletes SNKV 49,119 ops per second RocksDB 43,394 ops per second Random reads 50,000 lookups SNKV 69,174 ops per second RocksDB 54,029 ops per second Sequential scan 1,000,000 records SNKV 1,842,380 ops per second RocksDB 973,795 ops per second Sequential writes 1,000,000 inserts SNKV 122,580 ops per second RocksDB 438,452 ops per second Peak process memory usage SNKV approximately 2 MB RocksDB approximately 20 MB These results reflect architectural tradeoffs. RocksDB performs strongly in sustained write heavy scenarios, while SNK

Read the rest

V performs well in balanced read write workloads and scan heavy use cases. SNKV benchmark source https://github.com/hash-anu/snkv/blob/master/tests/test_benc... RocksDB benchmark source https://github.com/hash-anu/rocksdb-benchmark Feedback on benchmark methodology and configuration fairness is welcome.

2 points · Open discussion

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.