What is an HNSW index?
An HNSW index is the complete, built data structure produced by running HNSW’s construction process over a dataset of vectors — the layered graph itself, together with the raw vector data it references and whatever bookkeeping a specific implementation keeps alongside it, ready to be searched. It’s the tangible artifact this whole documentation is ultimately about: everything covered on the other glossary pages in this category — layers, neighbor lists, degree caps, the entry point — are pieces that together make up this one object, and “the index” is simply the name for that assembled whole once construction has produced it.
What does an HNSW index actually consist of, as a concrete collection of parts?
At its core, an HNSW index holds three things together. First, the raw vector data itself — the actual numeric embeddings for every item in the dataset, since the graph structure alone has no way to compute a distance without access to the underlying vectors it’s connecting. Second, the graph structure spanning every layer of the hierarchy: for each node, its maximum layer and the neighbor lists it maintains at every layer from zero up through that maximum. Third, a small amount of global bookkeeping needed to actually run a search against the structure — most importantly, a record of the current entry point, since every query needs to know where in the topmost layer to begin its descent.
Together, these pieces form a self-contained object capable of answering nearest-neighbor queries on its own: given a query vector, the index has everything it needs — the entry point to start from, the layer structure to descend through, and the raw vectors to compute distances against — without requiring any external information beyond the query itself.
How does an index’s memory footprint actually break down across these different pieces?
The raw vector data’s memory cost scales directly with the dataset’s size and ambient dimension — more vectors, or vectors with more coordinates, means proportionally more memory spent just storing the numbers themselves, independent of anything about the graph built on top of them. The graph structure’s memory cost is dominated overwhelmingly by the base layer, as covered on the Mmax0 glossary page, since it contains every node in the dataset with the largest per-node degree cap of any layer, while the sparse upper layers contribute comparatively little to the total, holding far fewer nodes with somewhat smaller degree caps. The bookkeeping overhead — tracking the current entry point and whatever metadata a specific implementation keeps — is typically negligible compared to the other two components for any dataset of meaningful size.
This breakdown is useful to keep in mind when reasoning about an index’s overall memory requirements: doubling M or Mmax0 roughly doubles the graph structure’s contribution to memory, while switching to a lower-precision vector representation, through the quantization techniques covered later in this documentation, primarily shrinks the raw vector data’s contribution instead — the two levers act on genuinely different parts of the same overall index.
What does it actually mean for an index to be “built,” and what can be done with it afterward?
An index is considered built once the construction process has finished inserting every vector in the initial dataset, at which point it’s ready to serve queries through the search process described throughout this glossary category. Being built doesn’t necessarily mean being frozen, though — many HNSW implementations support inserting additional vectors into an already-built index, extending it incrementally rather than requiring a full rebuild from scratch every time new data arrives, a capability covered in more depth in the dynamics-and-variants part of this documentation. An index can also, in most implementations, be saved to persistent storage and later reloaded, letting an application avoid repeating the potentially lengthy construction process every time it starts up, which is exactly the concern addressed on the index-persistence and serialized-index-size glossary pages.
Thinking of “the index” as this complete, addressable object — rather than as an abstract description of an algorithm — is also what makes it meaningful to talk about comparing two indexes, benchmarking an index’s recall, or reasoning about how an index’s memory footprint or query latency will behave under a specific workload, since all of those activities are really about characterizing the properties of this one concrete, built structure.
Having covered what an HNSW index actually consists of as a built, concrete object, the M-parameter and Mmax0 glossary pages are worth revisiting with this fuller picture of where their effects actually land within the index’s overall memory footprint. From there, the index-persistence and serialized-index-size glossary pages, under persistence and database concepts, pick up directly from here, covering what happens to this assembled structure once it needs to be saved and later reloaded.