The Algorithm Inside Every Vector Database: Understand and Tune HNSW in 20 Minutes

HNSW is the graph index inside pgvector, Qdrant, Weaviate, ChromaDB, and FAISS — three knobs control all of them: m (connectivity), ef_construction (build quality), and ef (query depth).

What you'll be able to do after this:

• Explain why HNSW finds approximate nearest neighbors in sub-millisecond time across millions of vectors — and why brute-force can't
• Tune m, ef_construction, and ef for the right recall/latency tradeoff in any vector database
• Benchmark your own collection and find the performance knee that fits your workload

Resource: Qdrant Essentials Course, Day 2: HNSW Indexing + YouTube walkthrough

How HNSW works

HNSW builds a multi-layer graph. Higher layers contain fewer nodes connected by long-range "highway" edges — they let a search jump quickly across the vector space. Lower layers are dense with local connections for fine-grained lookup.

At query time, search enters at the top (coarsest) layer, follows the closest edges downward through increasingly dense layers, and returns approximate nearest neighbors. This is typically 10–100× faster than brute-force scan, with 95–99% recall — which is why every major vector database uses it as the default index.

All the databases covered in this learning track use HNSW: pgvector, Qdrant, Weaviate, ChromaDB, and FAISS (IndexHNSWFlat).

The three parameters you control

Parameter	Controls	When set
m	Edges per node per layer — higher = better recall, more memory and build time	Index creation
ef_construction	Candidates explored during build — higher = better index quality, slower build	Index creation
ef (or ef_search)	Candidates explored per query — higher = better recall, slower queries	Query time (tunable live)

Starting values: m=16, ef_construction=200, ef=128. Raise m when recall matters more than memory. Raise ef at query time for a recall boost without rebuilding the index.

Hands-on walk-through (Qdrant course)

The Qdrant Essentials Day 2 course runs you through a 100K-vector benchmark:

1. Upload vectors with HNSW disabled — measure brute-force baseline latency
2. Enable HNSW with default params — observe the latency drop
3. Tune m and ef_construction, rebuild — measure recall against a ground-truth set
4. Use the HNSW Performance Benchmarking project to find the recall/latency knee for your collection

The YouTube video is the clearest visual walkthrough of the layer traversal before you run the code.

The same parameters exist in every major vector DB — they just use different names:

Database	m	ef_construction	ef at query time
Qdrant	m	ef_construct	ef
pgvector	m	ef_construction	hnsw.ef_search
Weaviate	maxConnections	efConstruction	ef
ChromaDB	M	ef_construction	ef

Once you understand the three knobs, you're fluent across all of them.

Sources: HNSW Indexing Fundamentals — Qdrant · HNSW Performance Tuning Demo · YouTube: Fast Vector Search with HNSW Indexing