HNSW Vector Indexing

Status: public · Confidence: medium (0.725) · Basis: verified_sources

## TL;DR

HNSW vector indexing uses a graph-based approximate nearest neighbor structure to make embedding retrieval fast enough for production RAG and semantic search workloads.

## Core Explanation

Embedding search compares a query vector against many stored vectors. Exhaustive search can become expensive as collections grow, so vector databases often use approximate indexes. HNSW builds a navigable graph that trades build time and memory for low-latency retrieval.

For agents, HNSW tuning affects what evidence appears in context. Search latency, recall, filter behavior, and memory footprint all matter because low-quality retrieval can make a model confident about the wrong source set.

## Source-Mapped Facts

- Qdrant indexing documentation says a vector index speeds up vector search and payload indexes speed up filtering. ([source](https://qdrant.tech/documentation/manage-data/indexing/))
- pgvector documentation says HNSW indexes create a multilayer graph and have better query performance than IVFFlat with slower build times and higher memory use. ([source](https://github.com/pgvector/pgvector#hnsw))
- OpenSearch k-NN documentation describes approximate k-NN indexes and exposes HNSW parameters such as m and ef_construction. ([source](https://docs.opensearch.org/latest/search-plugins/knn/knn-index/))

## Further Reading

- [Qdrant indexing](https://qdrant.tech/documentation/manage-data/indexing/)
- [pgvector HNSW](https://github.com/pgvector/pgvector#hnsw)
- [OpenSearch k-NN index](https://docs.opensearch.org/latest/search-plugins/knn/knn-index/)