PageANN: High-Performance Disk-Based ANN

• PageANN is a disk-based approximate nearest neighbor search framework that aligns graph nodes with SSD pages to mitigate I/O bottlenecks.
• It leverages representative storage and batched asynchronous reads to dramatically reduce page reads, yielding up to 10× speed improvements.
• The design optimizes memory–disk coordination, enabling efficient vector search even at minimal memory ratios.

PageANN is a disk-based approximate nearest neighbor search (ANNS) framework that co-designs a graph index with Solid-State Drive (SSD) page layout for high-performance and scalable vector search. It is introduced as a response to three bottlenecks in existing disk-based ANNS systems: long I/O traversal path, misalignment with storage I/O granularity, and high in-memory indexing overhead. Its central mechanism is a page-node graph in which one logical graph node corresponds to one physical SSD page, with each page storing vectors, page-level topology, and compressed representative vectors for next-hop selection. In the reported evaluation, this design yields 1.85×–10.83× higher throughput and 51.7%–91.9% lower latency than state-of-the-art disk-based ANNS methods across different datasets and memory budgets, while maintaining comparable high recall (Kang et al., 29 Sep 2025).

1. Problem setting and design objective

Approximate Nearest Neighbor Search is described as the core of vector databases and is used in applications ranging from information retrieval to bio-informatics. Graph-based ANNS methods achieve high query efficiency, but their scalability is constrained by available host memory. Disk-based ANNS mitigates memory usage by offloading data to SSDs, yet existing systems still incur substantial I/O latency because traversal remains storage-bound rather than compute-bound (Kang et al., 29 Sep 2025).

The reported motivation centers on three limitations. First, long I/O traversal paths persist as datasets grow to hundreds of millions or billions of vectors. Even on low-diameter graphs such as Vamana, graph traversal requires many hops, and each hop incurs multiple SSD reads. The paper reports that I/O latency accounts for over 90% of query time across DiskANN, SPANN, Starling, and PipeANN. Second, SSDs read at page granularity, often 4–16 KB, whereas traditional graph-based search may touch only a few vector records per page, producing read amplification. The cited read amplification values include 18.29× on SIFT100M and 20.08× on SPACEV100M for DiskANN, while Starling still incurs 1.28–1.95× amplification. Third, existing systems retain substantial memory-resident data structures, such as graph topology, PQ-compressed vectors, or in-memory traversal graphs. SPANN requires at least 30% of dataset size in DRAM and cannot run below that threshold; DiskANN, Starling, and PipeANN can go lower, but with latency or recall degradation due to heavier I/O (Kang et al., 29 Sep 2025).

These observations motivate a design whose main optimization target is not only graph quality, but also alignment between logical traversal and physical page access. A plausible implication is that PageANN treats SSD page utilization as a first-class index-design constraint rather than as a storage-layer afterthought.

2. Page-node graph and page alignment

PageANN introduces a page-node graph structure that aligns one logical graph node to one physical SSD page. The formal view given in the paper is $G = (V, E)$, where each node $v \in V$ corresponds to one SSD page $p$ and encodes three components: $X_p$, the set of vectors assigned to page $p$; $\mathrm{Adj}(p)$, the set of neighboring page-node IDs; and $R_p$, on-page compressed representative vectors of neighbors used for next-hop decisions without extra I/Os (Kang et al., 29 Sep 2025).

The graph is constructed from a high-quality vector graph such as Vamana. Similar vectors are clustered into the same page node in order to preserve local proximity and connectivity. For a chosen page-node capacity $n$ and hop parameter $h$, the construction picks a seed vector $v$ and collects up to $v \in V$0 nearest vectors within $v \in V$1 hops in the vector graph $v \in V$2; these vectors form a page node $v \in V$3. The procedure continues until all vectors are grouped. Page-level connectivity is then derived by aggregating outgoing edges from vectors in $v \in V$4 to vectors outside $v \in V$5, removing intra-page edges, and merging duplicate external connections to form $v \in V$6 (Kang et al., 29 Sep 2025).

A second key component is representative storage. Rather than duplicating all neighbor vectors, PageANN stores only compressed representatives of neighbors, denoted $v \in V$7, that are sufficient to guide next-hop selection from the current page. These representatives are derived from actual neighbors observed at the vector level and are encoded compactly to fit within the page budget. The paper further describes merging and pruning: edges to the same neighbor page are merged, and redundant information is pruned to maximize distinct, useful topology and representative content within one SSD page.

This page alignment changes the unit of traversal. In a traditional vector-node graph, visiting one node typically triggers many neighbor fetches. In PageANN, one hop maps to one SSD page holding $v \in V$8, $v \in V$9, and $p$0, so identifying next hops does not require reading neighbors’ pages immediately. This suggests that the reduction in graph hops and the reduction in physical page reads are made much more tightly coupled than in prior disk-based layouts.

3. Search procedure and I/O reduction

PageANN uses a two-phase search composed of in-memory routing followed by page-node traversal on disk. The in-memory phase uses an LSH-like hashing mechanism to produce good entry vectors. The disk phase traverses page nodes, computing exact distances to in-page vectors and estimated distances to neighbor representatives, thereby reducing immediate neighbor-page fetches (Kang et al., 29 Sep 2025).

The search algorithm maintains three data structures: a candidate set $p$1, implemented as a min-heap of vector IDs with estimated distances; a visited-pages set $p$2; and a result set $p$3 containing exact distances for vectors visited. Query processing begins by computing the query hash, retrieving vector IDs within a small Hamming radius $p$4 from a hash table $p$5, estimating distances using in-memory compressed values, and pushing these entries into $p$6. The page-node traversal then repeatedly pops the closest unvisited vectors, gathers their page IDs, skips pages already in $p$7, and reads up to batch size $p$8 pages in one I/O batch. For each loaded page $p$9, it computes exact distances to the vectors in $X_p$0 and adds them to $X_p$1, then estimates distances to neighbor representatives $X_p$2 and pushes those neighbor IDs into $X_p$3. The algorithm stops when $X_p$4 has no unvisited candidates, sorts $X_p$5, and returns top-$X_p$6 (Kang et al., 29 Sep 2025).

The paper attributes the latency reduction primarily to a reduction in page reads. Its query-time cost model is

$X_p$7

where $X_p$8 is the number of SSD pages read and $X_p$9 is per-page read latency. Since the paper reports that I/O dominates latency by more than 90%, reducing $p$0 is the central systems objective. PageANN pursues this through page-node alignment, representative storage, batched I/O, asynchronous reads, and skipping already visited or scheduled pages.

At Recall@10 = 0.9 and 30% memory ratio, the reported mean I/Os are reduced from 157.79–299.61 in the baselines to 59.93–85.14 in PageANN across SIFT100M, SPACEV100M, and DEEP100M. This reported decrease in page reads is presented as the direct mechanism behind the observed reduction in $p$1 (Kang et al., 29 Sep 2025).

4. Capacity model, memory–disk coordination, and lightweight indexing

PageANN constrains every page node to fit vectors, neighbor IDs, and compressed representatives into a single SSD page. The sizing formula reported in the paper is

$p$2

where $p$3 is page size, $p$4 is the size of counters for neighbor counts, $p$5 is bytes per neighbor ID, $p$6 is number of neighbor page nodes, $p$7 is bytes per compressed representative vector, $p$8 is number stored on-page, $p$9 is vector dimension, and $\mathrm{Adj}(p)$0 is bytes per dimension (Kang et al., 29 Sep 2025).

A defining feature of the framework is memory–disk coordination. The placement of compressed vectors depends on memory budget. Under low memory, compressed neighbor values $\mathrm{Adj}(p)$1 remain on-page, and redundancy is pruned or merged to fit page size. Under moderate memory, a hybrid policy places some compressed values in DRAM and the remainder on SSD pages. Under high memory, all compressed values are retained in DRAM, which frees page space for more vectors per page-node and shrinks the page graph. The stated goal is to maximize host memory utilization while minimizing query latency and storage overhead.

The in-memory component is intentionally lightweight. A small LSH-like routing index samples vectors, projects them onto random hyperplanes, encodes signs into binary hash codes, and maps codes to sampled vector IDs. Hamming distance is then used to approximate similarity for initial candidate selection. If memory permits, PageANN also caches frequently visited page nodes based on warm-up profiling and stores compressed vectors in contiguous arrays with sparse hash maps for ID lookups. The implementation uses tsl::sparse_map to reduce overhead and relies on an asynchronous I/O pipeline using io_submit and io_getevents (Kang et al., 29 Sep 2025).

This division of labor between DRAM and SSD is central to PageANN’s reported low-memory behavior. The paper states that PageANN maintains good performance even at very low ratios, down to approximately 0% memory ratio.

5. Construction pipeline, operating parameters, and reported performance

The construction pipeline begins with a high-quality vector graph $\mathrm{Adj}(p)$2, for example Vamana. Vectors are grouped into page nodes by selecting a seed vector, gathering up to $\mathrm{Adj}(p)$3 closest vectors within $\mathrm{Adj}(p)$4 hops, and filling remaining slots if needed. For each page, the system writes PageVecs, PageNbrs, and compressed neighbor vectors $\mathrm{Adj}(p)$5 into one SSD page. Vector IDs are reassigned according to page ID and offset so that query-time pageID lookup is $\mathrm{Adj}(p)$6 (Kang et al., 29 Sep 2025).

The paper identifies several operating parameters. Page size $\mathrm{Adj}(p)$7 determines the total page budget. Vectors per page $\mathrm{Adj}(p)$8 (or $\mathrm{Adj}(p)$9) reduce graph size when increased, but can hurt local precision and increase compute per page if too large. The number of representatives $R_p$0 (or $R_p$1) improves next-hop decisions without reads, but consumes page space. Graph degree $R_p$2 in $R_p$3 affects connectivity and recall. Search batch size $R_p$4 amortizes I/O setup and improves throughput, although excessively large $R_p$5 can increase contention for SSD bandwidth. Beam width or candidate pool $R_p$6 raises recall at the cost of more expansions. Cache size $R_p$7 reduces cold misses when workload locality exists. The practical evaluation uses fixed batched I/O size $R_p$8 and 16 query threads, with identical build-time settings across systems for graph degree, compression ratio, and candidate pool (Kang et al., 29 Sep 2025).

The reported experimental setup uses an Intel Core i9-14900K (24 cores, 4.3 GHz), 64 GB DDR4 RAM, 2 TB NVMe SSD, and Ubuntu 24.04 (WSL2). Datasets are SIFT100M, SPACEV100M, DEEP100M, SIFT1B, and SPACEV1B. Baselines are DiskANN, SPANN, Starling, and PipeANN. Metrics are Recall@10, latency in milliseconds, and throughput in QPS (Kang et al., 29 Sep 2025).

At Recall@10 = 0.9 and 30% memory ratio, the reported million-scale results are as follows. On SIFT100M, PageANN achieves 2749.36 QPS, 5.78 ms, and 85.14 mean I/Os, compared with DiskANN at 1099.62 QPS, 14.45 ms, and 187.43 mean I/Os; Starling at 1246.94 QPS, 12.75 ms, and 157.79 I/Os; PipeANN at 632.16 QPS, 25.16 ms, and 168.51 I/Os; and SPANN at 383.40 QPS, 20.86 ms, and 299.61 I/Os. On SPACEV100M, PageANN reports 3918.03 QPS, 4.05 ms, and 59.93 I/Os. On DEEP100M, it reports 2788.73 QPS, 5.07 ms, and 83.94 I/Os (Kang et al., 29 Sep 2025).

Across these datasets and memory budgets, the summary claim is 1.85×–10.83× higher throughput and 51.7%–91.9% lower latency while maintaining comparable high recall. On SIFT1B and SPACEV1B at 20% memory ratio, PageANN reports 1.9×–3.8× higher throughput and 48%–71% lower latency at Recall@10 = 0.9, and 2.2×–7.5× higher throughput and 55%–87% lower latency at Recall@10 = 0.95. In the memory-sensitivity study, throughput drops only approximately 8.7% at 20% memory and approximately 15.2% at 10% relative to 30%, whereas DiskANN and PipeANN fall below 20% of original throughput as memory decreases and SPANN fails below 30%. The minimum memory to reach Recall@10 = 0.9 on SIFT100M is reported as 1.2 GB for DiskANN, 3.2 GB for SPANN, 1.2 GB for Starling, 5.4 GB for PipeANN, and 0.05 GB for PageANN. The paper further states that even near 0% memory ratio, approximately 0.05 GB, PageANN outperforms baselines running with 10% memory ratio (Kang et al., 29 Sep 2025).

The concurrency study on SIFT100M at Recall@10 = 0.9 reports an 8.34× throughput increase from 1 to 16 threads. At 16 threads, PageANN yields +150% throughput versus DiskANN, +230% versus PipeANN, and +115% versus Starling, while latency rises by less than 92%, compared to 3–5× increases in baselines.

6. Scope, limitations, and practical significance

The paper explicitly limits its scope to static or periodically rebuilt indexes; dynamic insertion and deletion are out of scope. It describes dynamic disk-based systems as orthogonal and identifies integration of dynamic schemes, such as SPFresh-style in-place updates, as future work (Kang et al., 29 Sep 2025).

Several underperformance scenarios are identified. Very small page sizes, such as less than or equal to 4 KB with high-dimensional floats, may constrain $R_p$9 severely and reduce the benefit of page-node traversal. Highly heterogeneous vector distributions with weak local structure may reduce clustering effectiveness and make representative selection more difficult, possibly requiring larger $n$0 and therefore more page space. Extremely tight memory budgets coupled with very large graphs may force most representatives to remain on disk, slightly increasing per-page estimation error and widening recall-latency trade-offs. The paper also notes that PageANN benefits more on SSDs with lower page latency and good random-read performance, such as NVMe; on slower devices, tuning batch size $n$1 and caching becomes more important (Kang et al., 29 Sep 2025).

The implementation is in C++ and is approximately 6K LOC. It does not require specialized hardware and is presented as suitable for integration as a disk-resident index layer beneath existing VectorDBs, exposing standard ANN APIs for build and search. The open-source repository is reported as https://github.com/Dingyi-Kang/PageANN. Build time is slightly longer than the fastest baseline, reported as 1.68–3.50 hours on the evaluated datasets, due to page-node building and layout. CPU utilization is typically higher because PageANN overlaps I/O and computation and fully consumes loaded pages; however, the paper presents this as compatible with lower overall query latency and higher throughput (Kang et al., 29 Sep 2025).

The mathematical definitions reported alongside the system design are standard for the task domain. Euclidean distance is written as $n$2 for $n$3-dimensional vectors $n$4, and recall is defined as

$n$5

where $n$6 is the returned top-$n$7 set and $n$8 is the true $n$9 nearest neighbors. Within this formulation, PageANN’s contribution is to reduce $h$0 in the query-time cost model by aligning graph traversal with the physical unit of SSD access. This suggests that its significance lies not only in a new search heuristic, but in a storage-aware reformulation of graph-based ANNS for disk-resident operation.