Every number, wins and losses.

cargo run -p ffs-evals --release runs every scenario every time and prints both faster and slower paths. Numbers below are from a single run on Apple M-series silicon; machine spec, methodology, and the rationale for each comparator live in ffs-evals/src/main.rs. Losses are published in the same tables as the wins.

Headline results

* The starred ratios measure architectural stack cost rather than engine parity. "The loud numbers" below explains exactly what they do and do not show.

vs sled

100,000 random inserts and lookups, 1,000 range scans, fresh DB per run. The FFS tree is backed by a 4096-page buffer pool; reads and writes operate directly on cached page bytes with no node materialization on the hot paths. The engine page walks through the four changes that took inserts from 4676 ns to 429 ns.

vs instant-distance

10,000 random vectors at dim 128, M=16, k=10, recall measured against an exact brute-force oracle over 1,000 queries. The speedup is the epoch-stamped visited-scratch trick; recall stays even.

vs petgraph

50,000 vertices, 500,000 random directed edges, 1,000 traversal sources. The intended tradeoff is visible in the first row: FFS pays at append time for gap-preserving rel-list bookkeeping and collects on every read, because neighbors are a dense slice with cache locality an edge-list cannot match.

vs Postgres + pgvector

Postgres 17 + pgvector over the default Unix socket, same HNSW algorithm, same M=16 and ef_construction=200 on both sides. This is the cleanest apples-to-apples vector number in the matrix: the 3.01x gap is the SQL parse, libpq round-trip, and row deserialization between the application and the index — same algorithm, different stack shape.

vs LanceDB

10,000 vectors at dim 128, 200 queries at k=10. LanceDB's bulk load is much cheaper because it builds no index inline; FFS pays at insert time and queries are quick from the first insert. Which side of that tradeoff matters depends on the workload.

The loud numbers

5,000 vertices, 25,000 edges, 200 traversal sources. These ratios are loud and the README names what they actually measure. FFS here is a native Rust call — csr.neighbors(src) is a slice iterator. Kùzu runs each query through ANTLR parse, binder, planner, executor, and FFI marshalling even with a prepared statement; Neo4j adds a Bolt server round-trip on top. That stack is the cost real applications pay on every query, and FFS's collapsed-into-one-process design avoids it by construction. The apples-to-apples follow-up — FFS Cypher over stored graph data vs Kùzu Cypher — is named in the README as the next comparison to add. Until then, read these rows as stack-overhead evidence and remaining headroom, never as a sibling-database score.

Predicate-aware retrieval

20,000 nodes at dim 128, graph predicate dept_id == 0, top-10 nearest neighbours among matching nodes. The honest read: at low selectivity, post-filtering isn't faster — it's wrong. 11% recall means the user gets one of the ten results they asked for. Matching predicate-aware recall would need ~100x oversampling, which closes the latency gap anyway. The 2.5 ms query is the cost of correctness, paid once, inside one engine — a three-system stack pays serialization, network, and join-on-id on every call before it even gets the answer wrong.

Coverage

Where FFS is slower, the harness measures it. Where the comparator cannot run yet, the table says so. The aim is a comparator matrix for graph, vector, and typed storage paths rather than one hand-picked headline number.