Vector Indexing

No production RAG system scans a billion embeddings per query and still returns results in milliseconds — that requires a structure built specifically to skip most of the corpus without skipping the right answers. The trade a team makes when choosing that structure is set once, at build time, and rebuilding it at billion-scale is expensive enough that most teams get one real shot at choosing well. This topic sits directly downstream of the embedding model in the retrieval-augmented generation stack: a stronger index cannot fix a weak embedding, but the wrong index can throw away search quality the embedding model already earned.

Reading vector indexing in order: mechanism before scale

Start with how HNSW, IVF, and product quantization make nearest-neighbor search fast — it lays out the three index families and what each one is actually optimizing for. If the distance math and graph-traversal vocabulary feel unfamiliar, the prerequisites read on vector index internals fills in exact-vs-approximate search and what parameters like M, ef_construction, and nprobe actually tune before you touch a config file.

Once the mechanism is clear, the engineering limits at scale covers where the trade-offs turn brutal — read it before you provision hardware, not after a billion-vector index runs out of RAM. When you are ready to build, the FAISS, ScaNN, and DiskANN benchmarking guide turns dataset size and latency budget into an actual index choice, with a tuning order that beats reaching for more hardware first. For where the field is moving, the 2026 ANN-Benchmarks roundup tracks the shift toward mandatory quantization and disk-based scale. Close with what gets lost when an index decides which results you see if any of those dropped results could affect a person rather than a search ranking.

How vector indexing differs from similarity search algorithms

• Vector indexing is not the similarity metric. Similarity search algorithms define what “closest” means — the distance metric and the brute-force baseline. Vector indexing is the engineering layer built on top of that definition: it decides how much of the corpus a query actually touches, trading a controlled slice of accuracy for orders-of-magnitude speed. Swapping the index changes how fast and how completely you search; it never changes what “similar” means.
• HNSW is not IVF with a different name. Graph-based indexes like HNSW traverse a navigable small-world network toward the nearest neighbor; partition-based indexes like IVF instead cluster the corpus and search only the closest few clusters. They fail differently, too — HNSW’s memory grows with graph connectivity, IVF’s accuracy depends on cluster count and probe depth, and choosing between them is a dataset-size-and-latency-budget decision, not a popularity contest. The prerequisites read walks through the parameters that make the choice concrete rather than folklore.

Common questions about vector indexing at scale

Q: When should I pick IVF with product quantization instead of a full HNSW graph? A: When memory, not query latency, is the binding constraint — HNSW’s memory grows with graph connectivity, and at billion-scale that growth turns brutal before compute even becomes the bottleneck. IVF with product quantization trades some of that memory back for a measured recall loss. The engineering-limits read maps exactly where that trade starts to hurt.

Q: My index scores well on ANN-Benchmarks — why does it still underperform on my own data? A: Public benchmarks measure a fixed dataset and a fixed recall target that may not match your corpus’s dimensionality or query distribution. The build-and-benchmark guide treats public leaderboards as a shortlist, not a final answer, and benchmarks the finalists on your own data before committing.

Q: Do I need to switch index algorithms as my corpus grows from millions to billions of vectors? A: Often, yes. In-memory graph indexes like HNSW hit a hard ceiling that disk-based approaches were built to break — the 2026 ANN-Benchmarks roundup tracks DiskANN and quantization-first designs taking over exactly at that scale.

Q: If my vector index misses a relevant result, is that a bug I should fix? A: Not necessarily — approximate nearest-neighbor search is built to skip most of the corpus, and dropping some correct results is the mechanism working as designed, not a defect. What gets lost by design is worth reading before you decide the trade-off is acceptable for your use case.

Part of the retrieval-augmented generation stack · closest neighbour: similarity search algorithms. Coming to indexing from a software background? Start with the story: Debugging RAG Failures: Why Developers Need a New Diagnostic Model.