What is an entry point in HNSW?

The entry point in HNSW is the single node where every search begins, sitting in whatever the current topmost non-empty layer of the hierarchy happens to be, chosen simply as whichever node reached the highest layer assignment.
Created: Updated: 5 min read

The entry point in HNSW is the single node where every search begins — a designated starting node sitting in whatever the current topmost, non-empty layer of the hierarchy happens to be. Every query, regardless of what it’s actually looking for, starts its greedy descent from this one fixed node, and understanding exactly how that single node gets chosen and maintained clarifies a detail that can otherwise seem oddly arbitrary: how can starting from the same fixed point every single time possibly work well for wildly different queries scattered across an entire embedding space?

How does HNSW pick which node actually serves as the entry point?

The entry point isn’t chosen through any deliberate, query-aware selection process — it’s simply whichever node happens to have been assigned the highest layer during the random layer-assignment process applied at insertion time. Because layer assignment favors low layers overwhelmingly and makes higher layers exponentially rarer, at any given moment there’s typically just one node, or a very small handful, occupying the current tallest layer in the entire hierarchy, and that node is exactly the one designated as the entry point. There’s no consideration of what the node’s vector actually represents, no attempt to place it centrally within the data, and no ongoing optimization of its position — it’s purely a byproduct of the same random process that determines every other node’s layer assignment, with the entry point simply being whichever node that process happened to elevate the highest.

This might seem like an odd way to pick something as important as a search’s universal starting point, but it works precisely because the entry point’s job isn’t to be close to any particular query — its job is to be reachable and to sit in a layer sparse enough that a search starting from it can make large jumps quickly, regardless of which direction in the vector space the actual query happens to be located.

Why does starting from the same fixed node work well for queries scattered all across the embedding space?

The key insight is that the entry point doesn’t need to be near any specific query — it only needs to be a reliable, well-connected launching point from which a greedy search can reach any region of the space reasonably quickly. Because the entry point sits at the very top of the hierarchy, in the sparsest layer, its connections in that layer tend to span unusually large distances, exactly the kind of long-range shortcuts that let a search jump across large portions of the vector space in relatively few hops rather than needing to traverse a long, slow chain of only short, local connections. A search descending from the entry point isn’t trying to reach the entry point’s own neighborhood specifically — it’s using the entry point as a springboard, following whichever of its long-range connections happen to lead in a promising direction toward wherever the query actually sits, and progressively refining that direction as the search descends through denser and denser layers below.

This is really the same underlying idea that makes small-world graphs navigable in general: a small number of long-range connections, even ones that don’t directly point toward every possible destination, dramatically reduce the number of hops needed to get from an arbitrary starting point to an arbitrary destination, compared to a graph built only from short, local connections. The entry point works well as a universal starting point for exactly this reason, not because it’s positioned near any particular query, but because its position at the top of a well-built hierarchy gives it access to exactly the kind of long-range connectivity that makes fast navigation from anywhere to anywhere else possible.

What happens to the entry point as the index continues to grow through new insertions?

Because the entry point is simply whichever node currently holds the highest layer assignment, it can change over the life of an index: if a newly inserted vector happens to be randomly assigned a layer higher than any existing node has ever reached, that new vector becomes the new entry point, replacing whatever node previously held that role. This handoff happens automatically as a natural consequence of the same random layer-assignment process used for every insertion, with no special logic needed to detect or manage the transition — the index simply tracks whichever node currently sits at the top of the hierarchy and always begins searches there. Because higher layers become exponentially rarer as height increases, entry-point changes become less frequent as an index grows larger and its existing top layer becomes harder to exceed by chance, though they remain a normal, expected part of how an actively growing index behaves rather than something to be treated as unusual or error-prone.

Having covered how a single, seemingly arbitrary entry point actually supports efficient search across an entire embedding space, the HNSW-hierarchy and maximum-layer-of-a-node glossary pages are worth revisiting with this fuller picture in mind, since the entry point is really just a special case of the more general layer-assignment process those pages describe. From there, the greedy-navigation and best-first-search glossary pages pick up directly from here, covering exactly how a search actually moves once it’s begun its descent from this starting node.