When your RAG pipeline starts returning irrelevant chunks, the culprit is often not the embedding model but the vector index silently trading away recall for speed. While many teams default to HNSW because it is the de facto standard, IVF-PQ remains a compelling alternative that can cut memory usage by 10-20x and improve scan efficiency for billion-scale corpora. In this comparison, we dissect both algorithms—not just theoretical complexity, but real production trade-offs: build time, update patterns, GPU acceleration, and the exact parameters that make or break query latency. By the end, you will know which index to choose for your document corpus, query volume, and hardware budget.
HNSW (Hierarchical Navigable Small World) constructs a multi-layer graph where each node connects to neighbors at various resolutions. During a query, the search starts at the top layer and greedily descends. This yields exceptional recall—often exceeding 0.95 even at high query throughput. However, the graph structure requires storing all vectors in memory, plus edge lists. For a typical 768-dimension embedding (e.g., from all-MiniLM-L6-v2), each vector costs roughly 3 KB as raw floats. With 10 million vectors, that is 30 GB—and HNSW adds another 20-30% for graph edges (M=16, efConstruction=200). On a 64 GB RAM instance, this fits, but only barely. If your corpus grows to 100 million vectors, you need a cluster with 300+ GB, which inflates cloud costs. PostgreSQL’s pgvector implementation of HNSW has a similar memory profile, but you can enable the `hnsw.ef_search` and `hnsw.ef_construction` settings to fine-tune recall. Yet, memory remains the bottleneck.
Building an HNSW index is CPU-intensive. With M=16 and efConstruction=200, indexing 10 million vectors on a 16-core machine takes roughly 45 minutes. The graph construction is sequential—each insert updates neighbor lists, causing lock contention. In production, you typically build offline (e.g., during a nightly job) and swap the index, but that means your system serves stale embeddings for hours. Furthermore, HNSW parameters are non-obvious: increasing M improves recall but multiplies memory, while higher efConstruction slows build time without a corresponding query benefit. Tuning is more art than science.
IVF-PQ (Inverted File with Product Quantization) takes a completely different approach. It partitions the vector space into cells (clusters) using k-means. At query time, only the vectors in the nearest cells are scanned. To compress vectors, product quantization splits each vector into subvectors and replaces each subvector with a codebook ID. This shrinks a 768-dim vector from 3 KB to just 64 bytes if you use 16 subquantizers with 8 bits each (a common configuration). Memory drops from tens of GB to a few hundred MB. For example, 10 million vectors with PQ16x8 needs about 640 MB plus the inverted lists. That is a 20x reduction compared to HNSW. The catch: PQ encoding is lossy. Vectors that are similar but fall into different quantization cells may be missed during the coarse scan, causing recall to drop to 0.85 or lower if not tuned properly. Moreover, the k-means training step is expensive—clustering 10 million vectors takes hours on CPUs, though GPUs (e.g., via FAISS) accelerate it significantly.
HNSW achieves low latency (single-digit milliseconds) by following edges in the graph, touching only a few hundred vectors per query. In contrast, IVF-PQ scans all vectors in the selected cells—often tens of thousands. However, because each vector is compressed to 64 bytes, the memory bandwidth required per query is lower. On a server with NVMe storage and 300 GB/s memory bandwidth, scanning 50,000 compressed vectors costs ~1 ms. But if your cells are too large (nprobe set high), latency can spike to 10 ms or more. Modern databases like Milvus and Elasticsearch allow you to set `nprobe` dynamically per query, balancing recall and latency. Meanwhile, HNSW queries are memory-latency bound; they rely on random pointer chasing, which can be slower on NUMA architectures. In 2025, with DDR5 memory and 96-core CPUs, IVF-PQ often outperforms HNSW in terms of queries per second (QPS) when you accept a 5% recall drop.
Real-world RAG systems are not static; documents are added, updated, and deleted. HNSW supports incremental inserts elegantly: you just add a new node and connect it to its neighbors. Deletions, however, are problematic. Removing a node leaves orphaned edges, which require a global repair process. Most implementations (pgvector, FAISS) mark nodes as deleted but keep them in the graph, causing memory leakage and eventual performance degradation. IVF-PQ handles updates differently. Adding a new vector requires computing its cluster assignment, which is inexpensive, but if the k-means centroids drift as the corpus evolves, recall degrades. The standard solution is to periodically rebuild the index—e.g., every few days. In a production environment with frequent document updates (like a support ticket system), this rebuild cycle can become a DevOps headache. Some vector databases (like Qdrant) offer oversampling and re-clustering online, but they still require periodic maintenance windows.
GPUs alter the calculus. FAISS’s GpuIndexIVFPQ can handle queries at 10k+ QPS with latency under 1 ms, far exceeding HNSW’s CPU-only limit. The reason: GPU memory bandwidth (e.g., 2 TB/s on an A100) makes the brute-force scan of compressed vectors extremely efficient. In contrast, HNSW on GPU is poorly supported because graph traversal is sequential and not easily parallelizable. If you are running a high-traffic RAG service (e.g., 100 requests per second) and have a GPU available, IVF-PQ is the clear winner. But if your infrastructure is CPU-only, HNSW may still win on latency, especially for small corpora (<1 million vectors) where memory is not an issue.
Your choice of vector database often dictates which index you use. Here is a comparative reality check:
Deciding between HNSW and IVF-PQ boils down to three factors: corpus size, query latency budget, and hardware memory. For corpora under 1 million vectors, HNSW is usually simpler and faster to implement—just set `ef_search` to 100 and call it a day. For 10-100M vector corpora on a single node, IVF-PQ becomes attractive because you can fit the index in RAM, whereas HNSW would require a distributed cluster. But you must accept a 5-10% recall drop unless you invest in fine-tuning. A practical compromise is a hybrid approach: use HNSW as a coarse filter and IVF-PQ as a refinement stage. Some databases (like Weaviate) allow you to chain multiple indexes per query. This way, you can prune to the top 100 candidates with HNSW (which runs fast on a small pre-filtered set) and then re-rank with IVF-PQ on the exact vectors. This pattern gives you high recall without the memory penalty.
Do not rely on vendor benchmarks; they rarely reflect your embedding distribution and query patterns. To compare HNSW and IVF-PQ for your RAG workflow, follow this protocol:
In our experience, IVF-PQ often wins on P99 latency when the database is under high concurrency because it is compute-bound and parallelizes better than HNSW’s pointer chasing. But the difference narrows if your dataset is highly clustered (e.g., many duplicates) because HNSW’s graph shortcuts are more effective.
Two emerging trends might render this debate moot in 2026. First, learned indexes (like those from Google’s Learned Index research) use machine learning to predict vector locations, potentially outperforming both HNSW and IVF-PQ. However, they are not yet production-ready for dynamic corpora. Second, quantized HNSW (e.g., FAISS’s `IndexHNSWFlat` with scalar quantization) reduces memory while keeping graph traversal. This hybrid offers HNSW’s recall with a 4x memory reduction, close to IVF-PQ’s footprint. For now, if you are starting a new RAG project, I recommend building a proof-of-concept with both indexes into your actual database and running the benchmark above. The result will surprise you—many teams find that IVF-PQ eliminates the need for a larger instance, saving thousands of dollars per month, while only sacrificing 2% recall that can be recovered by re-ranking with a cross-encoder.
To make the call, write down these four numbers: your corpus size, your QPS requirement, your available RAM, and your target recall. If RAM is less than 10 GB and corpus exceeds 5M, choose IVF-PQ. If QPS > 500 and you have a GPU, choose IVF-PQ on GPU. If you need point-in-time exact recall (e.g., for legal or medical retrieval), HNSW is safer but consider a hybrid with vector re-scoring. For everyone else, start with HNSW because it is easier to tune, but monitor memory usage—if your index exceeds 60% of available RAM, migrate to IVF-PQ. Finally, always test with your own data; generic performance numbers are a starting point, not a verdict.
Next step: Extend your current RAG evaluation script to output recall@10 for both indexes at various parameter settings. Run it tonight, and you will see which one wins for your specific embeddings. Then adjust your vector database configuration accordingly.
Browse the latest reads across all four sections — published daily.
← Back to BestLifePulse