Click any words you think contain an error. Click again to unmark.
Mark at least one word to submit.
**The error is treating PQ as an alternative to HNSW.** They are not alternatives; they solve different problems and are typically combined.
Vector search has two orthogonal questions:
1. **Which vectors do I bother comparing against?** This is the job of an **index**: HNSW (graph), IVF (clustering), Annoy (trees), DiskANN. Without an index, every query compares against all N vectors (O(N) scan).
2. **How is each vector represented when stored and compared?** This is the job of a **compression scheme**: float32 (uncompressed), int8 quantization, binary quantization, **Product Quantization (PQ)**. Compression shrinks the per-vector storage and the per-comparison cost but does not reduce the number of comparisons.
PQ lives on axis 2. By itself, it makes each distance comparison much cheaper (32 byte table lookups instead of 1024 float multiplies) but you still do N comparisons per query. For a billion-vector corpus that is still ~30 seconds per query single-threaded.
**The canonical production pattern is IVF-PQ:** IVF partitions the corpus and picks a few partitions to scan per query (cutting candidate count from N to nprobe * (N/nlist)); PQ keeps each compared vector tiny (cutting per-comparison cost ~50x). Combined, this is what makes billion-scale ANN on commodity CPUs possible.
HNSW-PQ exists too: some libraries store PQ codes inside HNSW graph nodes. Same idea: HNSW navigates, PQ compresses.
**A correct way to phrase the original claim:** 'We're using IVF-PQ instead of pure-float HNSW because the memory savings dominate at billion scale.' That sentence respects the orthogonality.
**Error: the sentence treats PQ as a competitor to HNSW. PQ is a compression scheme, not an indexing strategy. The right framing is IVF-PQ or HNSW-PQ vs pure-float HNSW.**
*The two axes.* Vector search has two independent design decisions:
1. **Indexing strategy** (which vectors to compare): HNSW, IVF, DiskANN, Annoy, brute-force.
2. **Vector representation** (how each vector is stored): float32, float16, int8, binary, PQ, OPQ.
The two axes compose. You can have HNSW with float32 vectors (highest recall, biggest memory), HNSW with int8 (some compression), HNSW with PQ (heavy compression), IVF with float32, IVF with PQ (the canonical billion-scale pattern), and so on.
*Why PQ alone is not an index.* PQ encodes each vector as pq_m bytes (typically 32). At search time, with no index structure, you still scan all N vectors and compute the PQ distance to each one. Asymmetric distance computation (ADC) makes each per-vector cost cheap (pq_m table lookups + pq_m adds), but the scan is still O(N). At N=1e9 that is tens of seconds per query single-threaded; with parallelism, maybe a second. Not viable for interactive search.
*Why IVF-PQ works.* IVF partitions the corpus into nlist clusters and picks the top nprobe clusters to scan per query. The candidate set drops from N to ~nprobe * (N/nlist). For nlist=4096, nprobe=16, N=1e9: ~3.9M candidates scanned per query, not 1B. Each candidate's distance is computed via PQ-ADC at ~10 ns per comparison. Total per query cost lands in the millisecond range.
*Why HNSW-PQ works.* HNSW builds a navigable graph; PQ-encoded vectors live at the graph nodes. The graph traversal visits a small fraction of nodes per query (typically O(log N) hops with O(efSearch) candidates per hop). Each visited node's distance is computed via PQ. Combined: cheap navigation, cheap per-node distance.
Quick reference
TL;DR
PQ is a compression scheme, not an index. Without IVF or HNSW on top, you still scan all N vectors per query (just with cheap distances). The correct framing is IVF-PQ vs HNSW, not PQ vs HNSW.
Saying 'we use PQ instead of HNSW' is like saying 'we use lightweight backpacks instead of a map and trail signs to find our way through the forest faster'. The backpack (PQ) makes each step lighter; the map and trail signs (HNSW or IVF) tell you which way to walk. You need both. **PQ is a compression scheme** that makes every comparison cheap; **HNSW is an index** that tells you which comparisons to even try. Mixing the two categories shows the speaker has not yet separated them in their head.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Corpus under ~10M vectors Pure-float HNSW fits in RAM easily and gives higher recall. PQ's compression is unnecessary overhead and a recall hit.
Recall target is 0.99+ with no rerank stage PQ introduces quantization error that caps recall a few points below full-precision. If you cannot rerank, do not quantize.
Write-heavy workload requiring frequent codebook retraining Codebooks were trained on a snapshot. Heavy drift requires retraining, which is disruptive. Pure HNSW handles streaming inserts without retraining.
Quick scan · 2–4 min
Everything important, quickly.
3 min: spot the category error + name the two orthogonal axes (index vs encoding) + present the IVF-PQ / HNSW-PQ production patterns + offer the corrected sentence.
Side-by-side
Configuration
Index layer
Encoding layer
Billion-scale viable?
Pure float32 brute force
None (O(N) scan)
float32
No (seconds per query)
Pure PQ scan
None (O(N) scan)
PQ
No (still O(N), even if each comparison is cheap)
Pure float32 HNSW
HNSW
float32
Borderline (RAM is the bottleneck)
IVF-PQ
IVF
PQ
Yes (the canonical pattern)
HNSW-PQ
HNSW
PQ
Yes (higher recall, more memory than IVF-PQ)
Real-world examples
Real products, models, and research that use this idea.
1Faiss exposes IndexIVFPQ as the canonical billion-scale CPU index; pure IndexPQ exists but is a baseline, not a production target.
2Milvus offers both IVF_PQ and HNSW with PQ quantization; pure PQ scan is not a deployment target.
3Qdrant defaults to HNSW and offers PQ as an opt-in compression layer for vectors inside the HNSW graph.
4Weaviate's product quantization documentation explicitly notes that PQ is a compression scheme applied on top of HNSW, not a replacement for HNSW.
5Google's ScaNN combines IVF-style partitioning with PQ and learned codebooks (anisotropic loss); the index and encoding layers are still separate.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QCould you imagine a case where pure-PQ scan beats HNSW-PQ?
Sign in or go Pro to see the approach for this follow-up.
QWhy is IVF-PQ generally chosen over HNSW-PQ at the very largest scales?
Sign in or go Pro to see the approach for this follow-up.
QHow would you defend 'pure-float HNSW is still the right call for our 50M corpus'?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Treating PQ and HNSW (or IVF) as alternatives. They are orthogonal: compression vs index structure. Production systems combine them as HNSW-PQ or IVF-PQ.