How does HNSW behave on disk and tiered storage instead of RAM?

HNSW behaves considerably worse on disk than in RAM, because the random, unpredictable memory access pattern that graph traversal fundamentally requires is exactly the access pattern disks are worst at serving — this mismatch is severe enough that disk-oriented approximate nearest-neighbor search has generally moved toward graph designs built from scratch around disk access rather than simply relocating an ordinary HNSW graph onto slower storage.

Why does the random-access pattern that works fine in RAM become a serious problem on disk?

Reading from RAM at a random, unpredictable location costs roughly the same as reading from a nearby one — the access pattern barely matters. Disks, including solid-state drives, behave very differently: reading data scattered across many unrelated locations is dramatically slower than reading the same amount of data from a smaller number of contiguous regions, because each separate location typically requires its own discrete read operation with its own overhead, even when the total amount of data being read is identical either way. A graph search that jumps from node to node along edges scattered arbitrarily across a large dataset produces exactly this worst-case pattern once that data lives on disk instead of in memory — every single hop can mean a fresh, expensive disk access, and a search that might comfortably visit a few hundred nodes in RAM becomes dramatically slower once each of those visits costs a disk operation instead of a memory access.

What does a disk-friendly graph layout actually try to achieve?

The general goal is to reduce how many separate disk reads a typical search requires, which usually means designing the graph and its storage layout together rather than treating them as independent concerns the way an in-memory implementation reasonably can. Grouping a node together with its neighbors on disk, so that a single disk read retrieves useful data for several traversal steps at once rather than just one, is one common technique. Separating frequently accessed, “hot” portions of the graph from rarely accessed “cold” portions, and keeping the hot portion cached in whatever memory is available, is another — since even a disk-resident graph can benefit from an in-memory cache covering the small fraction of the graph that most searches actually touch most often.

How do alternative disk-oriented graph designs differ from adapting HNSW directly?

Rather than taking HNSW’s layered structure and simply trying to store it more efficiently on disk, some research has instead designed a proximity graph from first principles around disk-resident, billion-scale search — most notably a design called Vamana, which uses a robust pruning strategy during construction specifically intended to preserve a graph’s navigability using a single flat structure rather than HNSW’s multiple layers, tuned around the assumption that data will live on solid-state storage rather than entirely in memory. A related design called FreshDiskANN extends this same disk-oriented approach to handle a streaming workload of continuous inserts and deletes, addressing the same update-and-delete difficulties covered elsewhere on this site but under the added constraint of disk-resident data. These represent a genuinely different design philosophy from adapting HNSW to disk after the fact: building the graph’s construction and pruning strategy around disk access patterns from the very beginning, rather than treating disk storage as an afterthought layered onto an algorithm designed for memory.

When does it make sense to abandon an in-memory graph approach altogether?

The crossover point is fundamentally about whether a dataset’s vectors and graph structure can comfortably fit within the memory actually available on the hardware being used. When they can, an in-memory HNSW graph generally offers better raw query latency than any disk-oriented alternative, since even a well-optimized disk access is slower than a memory access. When the dataset is large enough that fitting everything in memory would require hardware that’s impractically expensive or simply unavailable, a disk-oriented design becomes the more realistic choice despite its higher per-query latency, because the alternative — refusing to scale past available memory — isn’t a choice at all for a system that genuinely needs to serve a dataset that size.

Having now covered accelerating and scaling HNSW across GPUs, specialized hardware, multiple machines, and disk-resident storage, the next part of this site shifts focus to evaluation — how to measure whether any of these approaches actually deliver the recall and latency a system needs, rather than simply how to build them. For the memory-versus-disk cost trade-off discussed throughout this page framed in terms of actual bytes and access counts, this site’s memory-and-storage glossary section covers those numbers directly.