Onyx-ANNS: Disk-Private ANN Search

• Onyx-ANNS is a disk-access-private approximate nearest neighbor search component that decouples traversal hints from full-vector retrieval in a trusted execution environment.
• It employs a three-stage pipeline—traverse, prune, and refine—to use compressed in-memory traversal hints and on-disk pruning hints, thereby minimizing bandwidth usage.
• Empirical evaluations demonstrate up to 5× bandwidth reduction with modest access count increases, making the system effective for secure ANN search under ORAM constraints.

Searching arXiv for the cited Onyx paper and closely related ANN systems to ground the article and citations. Onyx-ANNS is the ANN-search component of Onyx, a system for disk-access-private approximate nearest neighbor search running inside a trusted execution environment while storing the large ANN index on untrusted SSDs. Its role is not to provide obliviousness by itself, but to make the ANN layer bandwidth-efficient so that the ORAM layer can protect access patterns at acceptable cost. The design is motivated by the claim that oblivious ANN search over SSDs depends simultaneously on bandwidth and access count, and that prior co-designs assign these two objectives poorly across the ANN and ORAM layers. Onyx inverts that assignment: Onyx-ANNS minimizes bandwidth in the ANN layer, while Onyx-ORAM minimizes access count in the ORAM layer (Rathee et al., 22 Apr 2026).

1. System setting and design rationale

Onyx-ANNS targets a setting in which a vector database runs inside a TEE, but the ANN index is too large to fit economically in protected memory and must therefore reside on external SSD. In that setting, the host can observe disk traffic even if both index contents and queries are encrypted. The paper stresses that page- or block-level disk accesses can reveal which graph nodes or pages were touched during search, and that such leakage is dangerous because access patterns can be used to infer queries or returned documents (Rathee et al., 22 Apr 2026).

The immediate cryptographic response is ORAM, but the system motivation is that ORAM amplifies I/O cost in two dimensions at once: an access-count multiplier and a bandwidth multiplier. The paper argues that naively combining ORAM with ordinary disk-based ANN search is therefore too expensive. Conventional disk ANN systems were designed for plain SSDs, where small random reads are cheap enough that designers often optimize primarily for fewer accesses rather than fewer transferred bytes. Under ORAM, that choice becomes counterproductive because every unnecessary byte is amplified.

Within this argument, Onyx-ANNS is the ANN-layer mechanism that changes the I/O tradeoff. The paper’s central diagnosis is that prior oblivious ANN designs effectively minimize access count in the ANN layer and bandwidth in the ORAM layer, even though ANN search is approximate by nature and can therefore tolerate compressed or intermediate representations, whereas ORAM has no comparable fundamental lower bound on access count. This suggests a division of labor in which the ANN layer should aggressively reduce bytes transferred, while the ORAM layer should absorb responsibility for reducing the number of I/O operations.

A common misconception is to treat Onyx-ANNS as an oblivious ANN algorithm in isolation. The paper is explicit that it is not: its purpose is to make disk-resident ANN search ORAM-friendly by shrinking ANN-layer bandwidth, not to hide accesses on its own.

2. Internal representations and storage organization

Onyx-ANNS builds on DiskANN, but reorganizes both data layout and query execution around a three-step granular refinement strategy: $$\text{traverse} \rightarrow \text{prune} \rightarrow \text{refine}.$$ This structure is enabled by three different per-vector representations (Rathee et al., 22 Apr 2026).

The first representation is the traversal hint $H$, a highly compressed form stored in memory inside the TEE and used for approximate scoring during graph traversal. The second is the pruning hint $H$, described in the paper as a compact intermediate representation with higher fidelity than the in-memory traversal hints, stored on external storage, fetched together with graph neighborhoods during traversal, and used for candidate pruning after traversal. The notation $H$ is overloaded in the paper; context distinguishes in-memory traversal hints from on-disk pruning hints. The third representation is the full-precision coordinate vector $F$, stored separately on external storage and fetched only for the pruned candidate set.

The key structural change relative to DiskANN is a decoupling of traversal data from full vectors. DiskANN stores

$N(p)\|F(p),$

where $N(p)$ is the adjacency list of node $p$ and $F(p)$ is its full vector. Onyx-ANNS instead stores

$N(p)\|H(p)$

in one place and $H$0 separately. In the full system, these are placed in two separate ORAM instances: a traversal ORAM for $H$1, and a refinement ORAM for $H$2. The paper identifies this separation as architecturally important because traversal accesses are small, while full-vector accesses are larger.

The compact intermediate representation is the decisive innovation at the ANN layer. The pruning hints are constructed using product quantization, are substantially more precise than the traversal hints, and are an order of magnitude smaller than the full-precision vector. They are not retained in DRAM; instead, they are fetched from disk only when a node is visited. This allows the system to visit many graph nodes while paying the full-vector cost only for a filtered subset of candidates.

The significance of this layout is that it changes the granularity at which information is bought from storage. Traversal becomes cheap in bytes, because most node visits require only adjacency plus pruning-hint data. Exact reranking is deferred until after pruning. A plausible implication is that Onyx-ANNS is best understood not as a new graph index, but as a storage- and bandwidth-aware execution regime for a DiskANN-style graph index.

3. Query processing pipeline and mathematical structure

The search procedure takes result size $H$3, candidate list size $H$4, and pruned list size $H$5, with

$H$6

The paper states that $H$7 and $H$8 are fixed public parameters independent of the query in order to preserve obliviousness-compatible behavior (Rathee et al., 22 Apr 2026).

The first phase is traversal. Starting from a designated start node $H$9, the system performs greedy beam search. In the simplified pseudocode with beam width $H$0, it repeatedly selects the best unvisited candidate according to approximate distance on traversal hints,

$H$1

fetches

$H$2

inserts neighbors into the candidate set, rescoring them with traversal hints, and truncates the candidate list to size $H$3. In the full system, the top $H$4 unvisited candidates are explored per step. This phase visits exactly $H$5 nodes and makes exactly $H$6 external accesses, each of size $H$7.

The second phase is pruning. After traversal, the $H$8 candidates are reranked using the pruning hints that were prefetched during traversal, and only the top $H$9 are retained: $H$0 No extra disk access is required in this phase, because the pruning hints for all visited nodes have already been fetched.

The third phase is refinement. For each of the $H$1 survivors, the system fetches the full vector

$H$2

computes exact distances on the full-precision coordinates, and returns the top $H$3. This phase makes exactly $H$4 accesses, each of size $H$5.

The paper gives the total access count of Onyx-ANNS as

$H$6

compared with DiskANN’s

$H$7

Its central bandwidth argument is that the higher access count is acceptable because the expensive full-vector reads are no longer paid on every node visit. The paper summarizes this tradeoff with the bandwidth ratio

$H$8

The denominator has two terms: the smaller traversal block $H$9, and the amortized refinement cost $F$0. The mechanism is therefore explicitly multi-stage, graph-based, compressed, and reranking-based. It is not described as IVF-based or clustering-based.

A second common misconception is that simple traversal/refinement decoupling is sufficient. The paper argues the opposite: if pruning uses only the coarse in-memory traversal hints, pruning is too weak, so the system still reranks almost everything. The pruning-hint layer exists precisely to avoid that failure mode.

4. Security model, obliviousness, and leakage profile

Onyx-ANNS is designed to fit a security argument in which logical ANN behavior is regular and physical disk behavior is hidden by ORAM. The paper’s threat model assumes that the CPU package and enclave memory are trusted, that application code inside the TEE is trusted and correctly implemented, and that the adversary can observe and tamper with storage traffic. DRAM access patterns and other enclave side channels are out of scope (Rathee et al., 22 Apr 2026).

The paper is clear that Onyx-ANNS itself does not provide obliviousness. If its accesses were issued directly to disk, the host would still observe which candidate nodes were visited during traversal and which vectors survived pruning and were refined. The privacy guarantee depends on the combined system: Onyx-ANNS fixes the number and granularity of logical accesses, and Onyx-ORAM hides which logical blocks those accesses correspond to.

For search, the formal leakage profile described in the paper is narrow. Operation type is public, ORAM and ANN parameters are public, and the number and granularity of logical accesses depend only on these public parameters. Specifically, search makes exactly $F$1 logical reads of size $F$2 from the traversal ORAM and exactly $F$3 logical reads of size $F$4 from the refinement ORAM. Thus, public leakage includes the operation type, $F$5, $F$6, and block sizes, but not the identities of the graph nodes or vectors accessed.

This architecture has an important systems consequence. Because $F$7 and $F$8 are fixed public parameters, the ANN layer cannot adapt the number of logical accesses to the difficulty of the query in the usual way. Onyx-ANNS therefore improves privacy-compatible performance not by making the access schedule variable, but by making the bytes transferred within that fixed schedule as small as possible.

5. Empirical behavior and operating trade-offs

The paper attributes the following ANN-layer tradeoff to Onyx-ANNS relative to DiskANN at the same recall target: bandwidth reduction of up to $F$9, and access-count increase of at most $N(p)\|F(p),$0 (Rathee et al., 22 Apr 2026). At top-10, 90% recall, Table 2 reports bandwidth reduction over DiskANN of $N(p)\|F(p),$1 on SIFT, $N(p)\|F(p),$2 on MS-MARCO, $N(p)\|F(p),$3 on DEEP, and $N(p)\|F(p),$4 on WIKI, with access-count increases of $N(p)\|F(p),$5, $N(p)\|F(p),$6, $N(p)\|F(p),$7, and $N(p)\|F(p),$8, respectively. These figures are explicitly for Onyx-ANNS rather than for the full Onyx system.

The ablation against naive decoupling is central to interpreting these numbers. At 90% top-10 recall, naive decoupling achieves bandwidth reduction of only $N(p)\|F(p),$9 on SIFT, $N(p)$0 on MARCO, $N(p)$1 on DEEP, and $N(p)$2 on WIKI, while increasing access count by $N(p)$3, $N(p)$4, $N(p)$5, and $N(p)$6, respectively. This is presented as direct evidence that coarse traversal hints are inadequate as pruning hints.

In the appendix ablation where all variants are combined with Onyx-ORAM, naive decoupling is $N(p)$7 slower than DiskANN on SIFT and DEEP, roughly matches DiskANN on MS-MARCO, and beats DiskANN only on WIKI, where vectors are very large. By contrast, Onyx-ANNS improves throughput over DiskANN by $N(p)$8 on SIFT, $N(p)$9 on MS-MARCO, $p$0 on WIKI, and $p$1 on DEEP. The paper identifies two favorable conditions: large full vectors $p$2, and highly compressed in-memory traversal hints, since both increase the value of a stronger intermediate pruning representation.

The design also introduces a memory tradeoff. Because traversal blocks and refinement blocks are stored separately, the system needs two ORAM clients. The paper says this nearly doubles the ORAM-side memory footprint, but since ORAM client state is only a small fraction of total memory, end-to-end memory rises only by about $p$3. Pruning-hint size $p$4 is itself a tuning parameter: larger hints improve pruning quality but increase traversal block size. The paper states that $p$5 is chosen empirically per dataset to maximize bandwidth reduction, and gives example candidate sizes from the appendix: SIFT $p$6 B; MS-MARCO $p$7 B; WIKI $p$8 B; and DEEP $p$9 B.

At the full-system level, Onyx achieves $F(p)$0 lower cost and $F(p)$1 lower latency than the state-of-the-art oblivious ANN search system (Rathee et al., 22 Apr 2026). These results are system-level rather than ANN-layer-only, but they frame the importance of the bandwidth savings produced by Onyx-ANNS.

6. Position in the ANNS design space

Onyx-ANNS occupies a specific point in the broader ANNS design space. It is graph-based, derived from DiskANN, and optimized for disk-oblivious execution under ORAM. Its core problem is not generic query-time acceleration, but reducing SSD bandwidth under a fixed logical access schedule. That makes it distinct from both cluster-based accelerator work and from graph-oriented work that targets ordinary CPUs or GPUs.

Relative to ANNS-AMP, which targets cluster-based PQ ANNS with adaptive mixed precision, clustered pipeline stages, and a bit-serial accelerator, Onyx-ANNS addresses a different bottleneck. ANNS-AMP accelerates distance-heavy stages such as cluster locating and LUT construction in clustered PQ search and trades a small reported recall loss for hardware speed and energy gains; Onyx-ANNS instead restructures graph traversal, pruning, and refinement so that most node visits avoid bandwidth-intensive full-vector reads (Chen et al., 5 Jun 2026). The two systems therefore reflect different optimization layers: one is accelerator-centric and cluster-centric, the other storage-centric and graph-centric.

Relative to Flash, which accelerates graph indexing on modern CPUs through compact codes, SIMD-conscious distance tables, and access-aware graph memory layout, Onyx-ANNS is concerned with query-time disk bandwidth rather than CPU build-time distance computation. Flash shows that graph indexing time is largely a CPU distance-computation problem and that compact codes can preserve construction decisions while reducing memory stalls (Wang et al., 25 Feb 2025). This suggests a complementary relationship: Flash is relevant to how a graph index might be built efficiently, whereas Onyx-ANNS is relevant to how a graph index is searched efficiently when storage privacy is required.

Relative to Jasper, a GPU-native Vamana system with batch-parallel construction, lock-free streaming insertions, and RaBitQ-based sequential-access quantization, Onyx-ANNS again differs in objective and environment. Jasper targets high-throughput, updatable GPU graph ANNS with full device-memory residency and emphasizes occupancy, coalesced loads, and mutability under GPU constraints (McCoy et al., 11 Jan 2026). Onyx-ANNS assumes an SSD-backed TEE setting and optimizes bytes transferred through ORAM-compatible storage accesses rather than GPU kernel efficiency.

These comparisons help clarify what Onyx-ANNS is and is not. It is not a general-purpose compression layer for any ANN system, not a graph-construction method, and not a standalone obliviousness mechanism. It is a bandwidth-efficient ANN front end for a disk-access-private system, built around a three-stage graph-search pipeline and a compact intermediate representation that proactively prunes the majority of bandwidth-intensive full-precision accesses without hurting recall empirically (Rathee et al., 22 Apr 2026).