MyVector — real-dataset benchmark

Head-to-head (normalized — taller is better on every metric)

Full metrics

Accuracy / throughput tradeoff (ef_search sweep)

Notes & caveats

• Dataset: fashion-mnist-784-euclidean (ann-benchmarks) — 60,000 train × 784-d, 10,000 held-out test queries, L2/Euclidean. Index HNSW M=16, ef_construction=200.
• Recall@10 vs published ground truth: each query is scored against the dataset's published exact top-10 neighbors, so recall is directly comparable to ann-benchmarks numbers — not the brute-force self-check the synthetic dashboard uses.
• ef_search sweep 10→800 is measured warm (a discarded warmup pass runs first). The headline ANN QPS / latency / recall@10 cards and table are taken from the warm ef_search=200 sweep point, so every engine is compared at the same operating point. MyVector loads its whole index into memory at build; MariaDB warms its mhnsw graph cache lazily over the first ~1k queries, so a cold first-query measurement would understate it.
• Exact KNN is the brute-force baseline (full scan, ~0.3 QPS at 60k×784) — it exists to show how much the HNSW index buys you, not as a practical option.
• MariaDB cache: mhnsw_max_cache_size raised to 1 GiB (its 16 MB default thrashes to disk). MariaDB builds HNSW online during insert, so its "index build" is load time (no separate build phase) — much slower here (~240 s) but, once warm, its search is competitive-to-faster than MyVector on this dataset at recall ≈ 1.0.
• MariaDB ef_search floor: MariaDB floors mhnsw_ef_search to ~2×M (=32), so its ef_search=10 point is below even M=16 and hits an edge path that mis-measures low — the rest of its curve (ef≈20→800) is monotonic once each point is warmed per-ef. Read MariaDB from ef≈20 up; the headline uses the warm ef=200 point.
• Hardware: all engines on the same Ampere A1 host, each pinned to an identical 4 vCPU / 24 GB slice. 26.10 is the current MySQL Innovation release.