ffsdb

benchmark posture

FFS evals for graph, vector, and write-back engine paths.

The eval posture is measured first and caveated in public. Faster rows, slower rows, comparator stack overhead, machine class, and raw commands all matter more than a single heroic number.

Evals

cargo run -p ffs-evals --release

Comparator Measured path Result
Postgres + pgvector HNSW query, same M and ef_construction 3.01x faster
LanceDB HNSW query vs indexed IVF-PQ path 3.03x faster
LanceDB HNSW query vs brute-force path 4.78x faster
sled KV range scan over 100-key windows 3.94x faster
sled Random u64 insert path 2.89x faster
instant-distance HNSW query, dim 128, k=10 2.64x faster
petgraph 1-hop graph traversal 9.28x faster
FFS integrated Filter, traverse, write-back, reopen tested
Run command cargo run -p ffs-evals --release
Machine class Apple M-series local run, as documented in the README
Rule publish faster and slower paths; name the comparator stack being measured

Clean vector comparator: Postgres + pgvector uses the same HNSW algorithm, M=16, and ef_construction=200. In the README run, ffs::Hnsw queried at 126 us/query vs 380 us/query for indexed pgvector.

Loud graph-server numbers are included only with caveats: they measure FFS native CSR calls against Kuzu Cypher or Neo4j Bolt+Cypher parse/bind/plan/execute paths, so read them as stack overhead evidence, not final database parity.

Caveated path Result in README Read it as
FFS native CSR vs Kuzu Cypher ~29,000x 1-hop traversal Native slice iteration vs embedded Cypher parse/bind/plan/execute/FFI stack overhead.
FFS native CSR vs Neo4j Bolt+Cypher ~1,200x bulk load, ~195,000x 1-hop traversal Native in-process CSR vs server round trips plus Cypher stack; useful as stack-cost evidence.
Predicate-aware graph + vector 100% recall at 10% and 1% selectivity Filtered HNSW pays more latency than post-filtering, but avoids returning the wrong top-k under sparse predicates.

context for numbers