Benchmarks, honestly
Median of N runs, both engines warm, prepared statements on both sides, fsync to a real disk. Where SQLite wins, we show it — the chart is only useful if you can trust it.
AMD Ryzen 7 3700X · 32 GiB · ext4 on SATA SSD · rustc 1.95.0 · SQLite 3.50.2 · single-threaded
The scoreboard
Every CRUD operation, as a speed ratio. Right of the line, Arkeion is faster; left of it, SQLite is — and yes, the full scan is still theirs.
Durable writes — the core use case
Every committed transaction pays the fsync. Arkeion's append-only commit needs one fdatasync; SQLite at synchronous=FULL pays two. On real disk that flips the table — and it's what an audited engine does constantly.
Same guarantees — the fair fight
The scoreboard above races plain SQLite. But Arkeion always carries versioning, a per-commit hash chain, AS OF and verify(). Hand SQLite the same job — a full history table plus a per-write hash chain, in one transaction — and the gap widens: this is the cost of an audit trail SQLite must bolt on and Arkeion simply is.
The SQLite emulation reproduces neither the per-commit content hash nor a queryable snapshot, so these ratios are a lower bound on the real cost of matching Arkeion — which still ships AS OF, verify() and branching on top.
Full-text vs FTS5 — a split decision
The index ended up smaller than FTS5's; build and query speed are still FTS5's turf. The trade buys something FTS5 can't offer: versioned, provable, time-travelling search.
Prefix-compressed posting lists — and unlike FTS5, every posting is versioned, hash-chained and MATCH … AS OF searchable.
Vector search vs the field
SIFT 1M, 128 dimensions, L2, real top-100 ground truth, single query at recall ≈ 0.99. Under concurrent load it sustains ~700 qps on 8 cores; at recall ≈ 0.88 a single query does ~590 qps.
14–21× smaller than the HNSW indexes — it fits in a fraction of the RAM. Qdrant does not report a comparable file size.
Parallel and streaming (186 s → 64 s): the dataset is never materialized, so it scales to tens of millions of rows on a modest box.
Read it fairly: pgvector and Qdrant answer over localhost TCP, so a 0.05–0.2 ms round trip inflates their latencies; and IVF scans O(N) candidates at fixed recall while HNSW is O(log N), so dedicated graph engines pull ahead at tens of millions of vectors. HNSW itself is excluded by design here — its random-access graph is incompatible with copy-on-write versioning and time travel. Arkeion is the one file where vectors live next to SQL, full-text, branches and AS OF.
The price of durability — v0.13 vs FAISS
The hardest comparison we can make: FAISS is the reference ANN library — pure RAM, no durability, no transactions, no versioning, no SQL. Same box (a 4-core VM, so the bars above and below are not cross-comparable), same SIFT-1M, identical config on both sides: IVF 1000 lists, PQ16, exact rerank ×32. Recall@10 ≈ 0.99 on both, query at a time, one thread.
Within 2× of the in-RAM reference — from a versioned, durable file on disk. Before v0.13 the gap was 7–10×. FAISS batch mode on 8 threads reaches ~5,000 qps to Arkeion's 1,381 concurrent.
Smaller on disk
The same compressible dataset, written by both engines. Page packing plus pure-Rust LZSS — Arkeion started this work at 4.0 MB.
Run them yourself
# CRUD vs SQLite (point at a real disk, not tmpfs)
ARKEION_BENCH_DIR=/path/on/real/disk cargo bench --features bench-sqlite
# on-disk footprint
cargo run --release --example dbsize --features bench-sqliteA lesson we learned the hard way: on tmpfs the fsyncs are free and SQLite wins the durable writes. On a real disk it flips. Always bench on the disk you'll run on.