-
Assign a random maximum layer to the new vector
Each new element is assigned a random maximum layer. Higher layers are exponentially rarer than lower ones, producing a pyramid-like topology: only a small subset of vectors appear in top layers while most vectors remain near the base. This sparsity at higher layers keeps long-range routing efficient. The distribution is controlled by a level-distribution parameter (often tied toMand implementation defaults). -
Navigate from the top layer down to the target layer
Insertion starts from a global entry point (typically a node located in the top layer). At each layer, the algorithm performs a greedy search: move to the neighbor that is closer to the new vector repeatedly until reaching a local minimum (no neighbor is closer). That local minimum becomes the entry point for the next lower layer. Repeat this until you reach the layer where the new vector will be inserted. -
Connect the new vector to its neighbors
For every layer where the new vector should appear, HNSW performs a best-first search (candidate list size determined byefConstruction) to find the best neighbor candidates. The algorithm then connects the new node to up toMnearest neighbors at that layer. Connections are bidirectional—if A connects to B, B also links back to A—ensuring bidirectional navigability. -
Prune and select neighbors (diversification)
If connecting the new node would exceed a node’sMlimit, a neighbor-selection heuristic prunes connections to keep the closest and most diversifying neighbors. This diversification preserves search quality while preventing layers from becoming overly dense.

| Parameter | What it controls | Typical effect / guidance |
|---|---|---|
M | Maximum number of connections per node at each layer | Higher M → better connectivity and recall but more memory and maintenance overhead. Common defaults: 16 or 32. |
efConstruction | Candidate list size during index construction | Larger efConstruction → better-connected index and higher recall, at the cost of slower indexing and more memory during build. |
ef / efSearch | Candidate list size during queries | Larger ef → higher recall at query time, but with increased query latency. Tune to the desired recall/latency balance. |
- Increase
efConstructionand/orMto improve index quality (higher recall) — expect longer build times and greater memory use. - Increase query
efto improve accuracy at query time — expect longer queries. - Typical production strategy: tune
efConstructionandMonce (at index build time), then adjustefdynamically per-query to meet latency/recall requirements.
Tune
efConstruction to prioritize index-build quality and tune ef at query time to meet your recall versus latency goals. Higher values improve recall but consume more resources.- High recall: HNSW often achieves very high recall (commonly in the mid-90s to high-90s percentiles), approximating true nearest neighbors closely.
- Very fast queries: On modern hardware, many queries run in sub-millisecond to single-digit-millisecond ranges, making HNSW suitable for real-time applications.
- Tunable trade-offs:
M,efConstruction, andeflet you balance accuracy, build time, memory, and query latency. - Broad ecosystem adoption: Many vector databases and libraries use HNSW as a default or recommended index (for example, Pinecone, Weaviate, Qdrant). If you use production semantic search or recommendation systems, they’re likely powered by HNSW or a variant.

- Assign elements to exponentially distributed layers.
- Navigate from a top-level entry point down using greedy search.
- Connect new elements to up to
Mneighbors per layer using a best-first search sized byefConstruction. - Prune neighbors to preserve diversity and sparsity.
M, efConstruction, and ef lets you trade recall, indexing cost, memory, and query latency—making HNSW a practical default for production vector search.
That concludes the HNSW construction and adoption overview.