How does compression and quantization interact with an HNSW graph?

Compression and quantization interact with an HNSW graph by shrinking what each node’s vector costs to store, separately from the graph’s own connection overhead — this can meaningfully reduce total memory use, but it also introduces a genuine accuracy cost that shows up differently depending on whether the compression is applied only to storage or actually used while the graph navigates itself.

Where does an HNSW index’s memory actually go, once quantization enters the picture?

As covered in this site’s memory-layout page, an index’s footprint splits into the raw vector data, the graph’s own connection overhead, and smaller contributions from labels and allocator bookkeeping. Quantization targets the first of these directly, shrinking how many bytes each vector occupies, while generally leaving the graph’s connection overhead untouched — a graph with a given M still stores the same number of neighbor references per node regardless of how compressed the vectors underneath it are. This means quantization’s benefit is largest relative to total memory when vector storage is the dominant cost, and comparatively smaller once graph overhead itself makes up a large share of the total footprint, which is more likely at very high connection counts.

What’s the difference between simple precision reduction and product quantization?

The simplest form of compression just stores each number in a vector using fewer bits than the usual full-precision format — a compact 16-bit floating-point representation, or an even more compact 8-bit integer representation, cuts memory roughly in half or to a quarter respectively, at the cost of a small, generally tolerable loss of numerical precision in every value. Product quantization takes a more aggressive approach: it splits each vector into several smaller sub-vectors, runs a clustering procedure independently within each sub-vector’s slice of dimensions, and replaces each sub-vector with a reference to whichever cluster it landed in. This produces a far more compact representation than simple precision reduction, since a vector ends up stored as a handful of small cluster references rather than its full set of original numbers, but it also introduces more approximation, since two different original sub-vectors that happen to land in the same cluster become indistinguishable from each other after compression.

What happens when the graph navigates using compressed vectors instead of the originals?

There’s an important distinction between compressing vectors purely for storage, while still using the original, uncompressed values whenever an actual distance needs computing, and using the compressed representation directly during the graph’s own navigation. The first approach pays a decompression cost at query time but preserves the graph’s original accuracy characteristics, since every distance calculation during traversal is still exact. The second approach — navigating using approximate distances computed directly from compressed vectors — is faster and uses less working memory during search, but means the graph itself is being explored using a distorted, lower-fidelity picture of the actual distances between points, which can degrade the accuracy of the traversal in ways separate from and additional to whatever error the compression itself introduces to the final ranking. Whether a system compresses only for storage or compresses all the way through navigation is a real design choice with a real accuracy consequence, not merely an implementation detail.

Why does reranking with full-precision vectors matter?

A common and effective pattern splits search into two stages: use fast, approximate distances — computed from compressed vectors — to quickly narrow a large dataset down to a modest set of promising candidates, then recompute exact distances using the original, full-precision vectors for just that small candidate set before producing the final ranked results. This captures most of quantization’s speed and memory benefit, since the expensive, exact computation only ever runs against a small final candidate pool rather than the whole graph traversal, while substantially recovering the accuracy that navigating on compressed vectors alone would have sacrificed. This reranking step does require keeping the original full-precision vectors available somewhere, even if only the compressed versions are used during the bulk of the search, which is itself a memory trade-off worth accounting for rather than assuming compression eliminates the need for full-precision data entirely.

Compression addresses memory, but a sufficiently large dataset eventually runs into constraints compression alone can’t solve, which the next part of this site turns to — running HNSW across GPUs, specialized hardware, and more than one machine. For the underlying mechanics of product quantization covered here at a conceptual level, this site’s compression-and-quantization glossary section has a dedicated page working through the clustering procedure in more depth.