Nearest and Fastest
HNSW vs IVF vector-search indexes, measured on the same vectors
The measured result
HNSW answered high-recall queries faster (0.9997 recall at 0.05 ms), while IVF built 5× faster (2.9s vs 15.7s) and used less memory (52 vs 66 MB). Neither dominates - the index follows your scarce resource.
0.05 ms
HNSW query @ 0.9997 recall
5×
faster build (IVF)
100%
reproducible (Docker)
What's inside
- Approximate nearest-neighbour search and its three costs: recall, latency, memory.
- How the IVF index partitions and probes, with its nlist/nprobe knobs.
- How the HNSW graph is built and searched, with its M/ef knobs.
- A measured recall-vs-latency comparison from a reproducible Docker harness.
- A workload-driven framework for choosing an index, with four worked cases.
- A benchmarking protocol and full references to the primary literature.
Table of contents
- Preface
Preface
Frames the book as a narrow, practical comparison of the two dominant ANN index families, IVF and HNSW, aimed at helping an engineer reason about which index serves a given workload.
- Chapter 1
The Vector Search Problem
Explains why exact nearest-neighbour search doesn't scale, defines approximate nearest neighbour (ANN) search and recall@k, and frames the three coupled costs - recall, query latency, and memory/build time - that every ANN index trades off.
- Chapter 2
Inside the IVF Index
Walks through how the inverted file index partitions vectors into k-means cells (nlist) and probes only the nearest few (nprobe) at query time, explaining why IVF is cheap to build and compact in memory, plus its nprobe recall ceiling and product quantization as a compression option.
- Chapter 3
Inside the HNSW Index
Explains how HNSW builds a layered navigable proximity graph and answers queries by greedy descent from sparse upper layers to a dense bottom layer, covering the M/ef_construction/ef parameters and how HNSW trades memory and build time for fast, high-recall queries and easy incremental insertion.
- Chapter 4
The Measured Comparison
Reports the book's reproducible benchmark of HNSW (hnswlib) versus IVF (FAISS IndexIVFFlat) on 100,000 clustered 128-dimensional vectors, showing both reach ~0.9997 recall@10 but HNSW answers queries faster while IVF builds over 5x faster and uses less memory.
- Chapter 5
Choosing an Index
Converts the measured trade-offs into a decision framework - ordered by memory constraints, recall/latency targets, and build/update patterns - and applies it to four representative workloads.
- Chapter 6
Conclusion: Measure Your Own Vectors
Restates the central trade-off (no index minimizes recall, latency, and memory simultaneously), gives a five-step protocol for benchmarking your own embeddings, and points toward related techniques like product quantization, DiskANN, and hybrid designs.
Who this is for
- Engineers building retrieval systems
- Engineers building recommendation systems
- Engineers building retrieval-augmented generation (RAG) systems
- Anyone choosing a vector database or an index within one
- Readers who want to reason about a workload's scale, recall target, update rate, and memory budget rather than trust a default index choice
The preface states that familiarity with embeddings and with big-O reasoning is enough, and that where theory is required it is built up from first principles.
How this was measured
The benchmark (in the bench/ directory, reproducible via `docker build -t vectorsearch-bench bench/` then `docker run --rm vectorsearch-bench --n 100000 --d 128 --q 1000 --k 10`) built an HNSW index (hnswlib, M=16, ef_construction=200, ef swept 10-200) and an IVF index (FAISS IndexIVFFlat, nlist=1024, nprobe swept 1-64) over the same 100,000 vectors of dimension 128, drawn as a Gaussian mixture of 1,000 clusters (sigma=0.10), and answered the same 1,000 queries (k=10, seed 42) against exact brute-force L2 ground truth (FAISS IndexFlatL2). It directly measured recall, per-query latency (single-threaded for both engines), build time, and index size on an AMD Ryzen 7 5700X under Docker Desktop (python:3.11), dated 2026-06-30. External sources are cited only for background not measured here - the HNSW design (Malkov and Yashunin) and product quantization as a compression technique - while everything in the results table and recall-latency figure is drawn directly from this harness's output (bench/results.json).
From the preface
A vector search system answers one question repeatedly: given a query vector, which stored vectors are closest to it? When the collection is small, the exact answer is cheap. When it holds millions or billions of embeddings, exact search becomes too slow, and the system turns to an approximate index that trades a small amount of accuracy for a large gain in speed.
Frequently asked
What exactly does the benchmark measure?
For both HNSW (hnswlib) and IVF (FAISS IndexIVFFlat) built over the same 100,000 clustered 128-dimensional vectors, it measures build time, index size, recall@10 against exact brute-force ground truth, and single-threaded per-query latency, sweeping HNSW's ef and IVF's nprobe to trace the full recall-versus-latency curve.
Do I need to run the harness myself?
No - the measured numbers and figures are already reported in Chapter 4 and the appendix. But the harness in bench/ is built to be reproduced with one Docker command, and the book repeatedly stresses that absolute results depend on hardware, data, and configuration, so the recommended next step is to re-run it on your own embeddings.
Is this beginner-friendly?
The preface says familiarity with embeddings and with big-O reasoning is enough to follow the book, and that where theory is required it is built up from first principles.
Which index is actually faster, HNSW or IVF?
Neither is universally faster. In the measured run, both reached recall@10 of 0.9997, but HNSW got there at 0.050ms per query versus IVF's 0.064ms, while IVF built more than five times faster (2.9s vs 15.7s) and used less memory (52.5MB vs 66MB). The book's framework says the right index depends on which resource - memory, build time, or query latency - is scarce for your workload.
Does the book cover compressed or billion-scale indexes like product quantization or DiskANN?
The benchmark itself only compares uncompressed IndexIVFFlat against HNSW. The conclusion mentions product quantization, disk-resident indexes such as DiskANN, sharding, and hybrid designs as related next steps, but none of those are measured in this book's harness.
What dataset does the benchmark use - real embeddings?
No, it uses synthetic data: 100,000 vectors of dimension 128 drawn as a Gaussian mixture of 1,000 clusters, chosen because clustered vectors mimic the neighbour structure real embeddings have, whereas uniform-random vectors have essentially no neighbour structure in high dimensions and would misrepresent the problem.
Convinced? Get the full book.