1.64×
faster sequential writes
232K vs 142K ops/s
1.85×
faster sequential scan
2.89M vs 1.56M ops/s
~2×
faster updates & deletes
31K vs 16K ops/s
1.77×
faster random reads
160K vs 90K ops/s
SNKV vs SQLite
Operation-by-Operation
SQLite uses a WITHOUT ROWID table with a BLOB primary key — the fairest possible comparison. Both share identical page cache, WAL, and sync settings. All differences are purely the SQL layer cost.
SNKV
SQLite (WITHOUT ROWID)
Sequential Writes
Random Reads
Sequential Scan
Exists Checks
Mixed Workload
80% read / 20% write
80% read / 20% write
Random Updates
Random Deletes
Bulk Insert
1K rows per transaction
1K rows per transaction
Methodology
- Dataset: 1,000,000 records, 16-byte random keys, 100-byte values
- Runs: 3 independent runs on a fresh database file; best time reported
- Config: WAL journal mode,
synchronous=NORMAL, 2000-page (8 MB) page cache, 4096-byte pages — identical for both engines - SQLite schema:
CREATE TABLE kv (k BLOB PRIMARY KEY, v BLOB) WITHOUT ROWID— single B-tree keyed on the same field, prepared statements for all DML - Peak memory: Both SNKV and SQLite use ~10.8 MB RSS — they share the same pager and page cache infrastructure
- Platform: Linux x86-64, NVMe storage
Analysis
Why SNKV Is Faster
SNKV and SQLite use the same B-tree storage engine at the bottom. Every performance difference comes from what each layer adds on top of it.
No SQL parsing
Each SQLite operation tokenises, parses, and validates a SQL string before execution. SNKV calls the B-tree API directly — zero parsing overhead per operation.
No query planner
SQLite chooses an execution plan for every statement. For KV access the plan is always "seek the primary key" — SNKV does exactly that without the planning step.
No VDBE interpreter
SQLite compiles queries to bytecode run by a virtual machine. SNKV calls compiled C functions. No bytecode dispatch loop on the critical path.
Cached read cursor
SNKV keeps a persistent read cursor open per column family. SQLite opens and closes a new cursor for each statement. Cursor open/close touches the pager — SNKV skips it on every read.
Updates & deletes: ~2× gain
These show the largest gap because each SQLite call parses, plans, and executes a full
UPDATE or DELETE statement. SNKV is a direct B-tree seek + in-place write.Bulk insert: 1.17× gain
The smallest gap — both commit a single large B-tree transaction, so per-row overhead dominates. Prepared statements close the gap; the storage cost is nearly equal.
Source
Run It Yourself
Both benchmarks are open source. Clone and build to reproduce results on your hardware.
C benchmark — SNKV
# From the SNKV repo root
make test
./tests/test_benchmark
C benchmark — SQLite comparison
# https://github.com/hash-anu/sqllite-benchmark-kv
git clone https://github.com/hash-anu/sqllite-benchmark-kv
cd sqllite-benchmark-kv
make
./sqlite_benchmark
Python benchmark — SNKV vs diskcache
# From the SNKV repo root
pip install diskcache snkv
python python/examples/benchmark_diskcache.py
Additional comparisons against LMDB and RocksDB:
LMDB — github.com/hash-anu/lmdb-benchmark
RocksDB — github.com/hash-anu/rocksdb-benchmark