Benchmarks

Every number here comes from crates/fenec-bench and can be reproduced with a make target. The method is written out below the table, because a number without one is a claim, not a measurement.

Against SQLite and pgvector

Same data, same process, same distance kernel. SQLite 3.46 and PostgreSQL 17 with pgvector 0.8.6, on an Apple M-series, 100 000 rows × 128 dimensions with clustered embeddings.

make pgvector-up      # start PostgreSQL + pgvector in Docker
make compare          # without it, that arm is skipped

Method

• All three follow the same workflow: bulk load first, index after. That is already the recommended order for SQLite and PostgreSQL; in fenecdb create index exists for exactly this.
• SQLite: WAL with synchronous=NORMAL, the bulk write in one transaction, the index built afterwards. fenecdb does not fsync per write.
• PostgreSQL: in Docker, bulk load with COPY, then hnsw (m=16, ef_construction=200) — the same parameters as fenecdb. At query time hnsw.ef_search = 64, again matching fenecdb's setting.
• Vector distance is computed by the same code in all three. What is measured is the engine's cost of fetching the data, not the arithmetic.
• SQLite's core has no ANN index, so a vector search there is a full scan. The comparison is therefore exact against exact first, with ANN on a separate row.
• The write is split in two stages, rows and index. A single "total" would weigh an engine that builds an ANN index and one that does not on the same scale.
• The PostgreSQL figures include a 0.40 ms TCP round trip, about 40% of its ANN time. That is not a measurement flaw, it is the client-server architecture.

How to read the numbers

fenecdb leads on raw write speed: 900 k rows/s, more than twice SQLite's. The append-only segment store reduces a write to appending to an arena — no B-tree rebalancing, no page splits.

It leads on index build too, 10.2 s against pgvector's 14.2 s at the same m and ef_construction. SQLite's 0.03 s is not an ANN index but a single-column B-tree; that cost does not vanish, it is deferred to query time, where a vector search takes 31.3 ms — 171× slower than fenecdb's ANN.

The one real loss is reopen. SQLite opens in 1 ms because it loads nothing, reading pages as it needs them. fenecdb pulls the vector arena into memory and validates the graph: 117 ms. That is not a shortcoming but the other side of the same coin — it is why queries are 3–171× faster. The measured break-even is four vector queries; after that fenecdb is ahead on the total.

fenecdb leads on disk as well, 2.5× smaller than pgvector. PostgreSQL's extra is MVCC row headers, WAL and the visibility map: the price of concurrent transactions. The single-writer model does not need it.

Scale measurement

Apple M-series, single thread, --release. 100 000 documents × 128 dimensions, clustered embedding distribution.

make bench
cargo run --release -p fenec-core --example bench

Without a persisted graph, reopening the same data takes 10.2 seconds — the index is rebuilt from scratch, which would make a page refresh in the browser unusable. The graph record makes that roughly 90× faster and costs 11% more space in the image, 52.1 MB to 57.9 MB.

The ef and recall trade-off

cargo run --release -p fenec-core --example bench -- 100000 128 --ef 200
make sweep      # walks the trade-off on both distributions

The default is 100: recall is complete and it is still roughly 7× faster than the engines compared above. It is tunable per query — get docs near embed $1 ef 200 limit 10 — and exact performs a full scan when you want ground truth.

On uniformly random vectors — the pathological case for any ANN index, where in 128 dimensions all distances converge and no neighbourhood structure survives — recall at the same ef is around 82%. Real embedding models output clustered data. --uniform measures that worst case deliberately.

Build-side tuning

100 000 × 128, single-threaded measurement:

If write speed matters more than the last point of recall, @hnsw(cosine, ef_construction=100) gains 19%.

Half precision

Same data, 100 000 × 128, clustered. The trade is explained in How it works.

Memory

make memory       # for calibrating --max-memory

The footprint is an early warning rather than a guarantee. A third of the container memory is a sensible --max-memory: it covers both this 60–75% ratio and compact's 3× peak. Details in Limits.

Binary size

fenec-pg stays on the release profile on purpose: a connection thread that panics unwinds and takes down only its own session, and the server stays up. The cli profile turns panic unwinding into abort, which is right for a single process with nothing to recover.