Part ofRAG Engineer·Week 1: Embeddings & Vector Search·question 5 of 6View roadmap →

Spot the conceptual error: 'We're using PQ instead of HNSW for our vector index because PQ is faster.'

Spot the error·Medium·4.0 · 0·~2 min·Asked atZilliz·Relevant atNVIDIA

Attempt it

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.

Memory aid

Easy to grasp

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.

Key concepts

Vector databases Embeddings

Detailed answer & concept explanation

~2 min read

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.

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.

Faiss exposes IndexIVFPQ as the canonical billion-scale CPU index; pure IndexPQ exists but is a baseline, not a production target.
Milvus offers both IVF_PQ and HNSW with PQ quantization; pure PQ scan is not a deployment target.
Qdrant defaults to HNSW and offers PQ as an opt-in compression layer for vectors inside the HNSW graph.
Weaviate's product quantization documentation explicitly notes that PQ is a compression scheme applied on top of HNSW, not a replacement for HNSW.
Google'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?

QWhy is IVF-PQ generally chosen over HNSW-PQ at the very largest scales?

QHow would you defend 'pure-float HNSW is still the right call for our 50M corpus'?

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.

60-second cheat sheet

The night-before-the-interview bullets. Scan these on the way to the call.

References

Primary sources. Skim if you want the original framing.

Next in this stepContinue