Papers
Topics
Authors
Recent
Search
2000 character limit reached

RemoteANN: A Native Vector Search Engine for Cloud Object Storage

Published 18 Oct 2026 in cs.DB and cs.IR | (2610.25172v1)

Abstract: Vector search engines built on cloud object storage have drawn growing attention from both academia and industry. These systems typically adopt a disaggregated storage-compute architecture, persisting the primary vector payload in object stores (e.g., Amazon S3) while retaining compact index metadata on compute nodes. However, conventional vector indexing structures are not natively tailored to the pronounced network latency and per-request access costs of cloud object stores, resulting in network I/O amplification, degraded query throughput, and higher API expenses. To resolve these challenges, we present RemoteANN, a vector search engine explicitly co-designed for cloud object storage across indexing and querying. To mitigate the dominant network I/O bottleneck, RemoteANN couples an Inverted File (IVF) index with RaBitQ quantization, further optimized by inter-cluster and intra-cluster data reordering for improved data locality. Building on this tailored data layout, RemoteANN's query engine combines cluster pruning, fine-grained Range-GET requests, request merging, and local NVMe SSD caching, dramatically reducing discrete storage requests and network transfer volume without sacrificing accuracy. To address the index construction bottleneck, we further develop QGKMeans, which substantially reduces construction latency without compromising clustering quality. Extensive evaluations on real-world datasets demonstrate that, compared with representative baselines, RemoteANN achieves up to a 5.9×5.9\times throughput speedup while issuing up to 16.1×16.1\times fewer object storage requests at 97% target recall.

Summary

  • The paper introduces RemoteANN, achieving up to $16.1 imes$ fewer object-storage requests and $5.9 imes$ higher throughput than baselines when searching near-neighbors in cloud-based vector data, demonstrating it is the speed and cost leader at approx. 97% recall.
  • RemoteANN employs IVF with RaBitQ built for Cloud, leveraging locality-aware vector placements, analytical pruning, fine-grained Range-GET, request merging, and NVMe caching, to optimize index and query processing with cloud specifications.
  • The system includes QGKMeans for fast index construction, ensuring operational feasibility at large scales by employing intelligent centroid assignment that matches state-of-the-art clustering speed while retaining recall performance in benchmarks.

Problem setting and system thesis

RemoteANN addresses approximate nearest-neighbor search when the vector payload is stored in cloud object storage and the query engine runs on a separate compute instance. This deployment model offers elasticity, durability, and storage-cost advantages, but it changes the dominant performance objective relative to in-memory or local-SSD ANN systems. Object storage imposes substantial time-to-first-byte latency and charges primarily by discrete retrieval requests. Consequently, an index that is acceptable on local storage can become inefficient when each cluster or graph hop induces a remote request.

The paper’s central thesis is that cloud-native vector search requires joint optimization of the ANN index, physical data layout, query execution, and storage hierarchy. RemoteANN therefore selects an IVF structure rather than a graph index, because IVF can retrieve candidate clusters with a bounded number of remote round trips. It combines IVF with RaBitQ quantization, locality-aware vector placement, analytical pruning, fine-grained Range-GET operations, request merging, and local NVMe caching. Index construction is accelerated separately through QGKMeans.

This is a systems paper rather than a proposal for a new ANN index family in isolation. Its contribution lies in aligning the index’s logical access pattern with the latency and pricing model of object storage. The evaluation reports up to 5.9×5.9\times higher throughput and up to 16.1×16.1\times fewer object-storage requests than representative baselines at approximately 97% recall (2610.25172).

Architecture and storage layout

RemoteANN uses a three-level hierarchy: DRAM on the compute node, local SSD, and remote object storage. IVF centroids and compact routing metadata are pinned in DRAM. The primary vector payload remains in object storage, allowing the system to retain the scalability and elasticity benefits of disaggregated storage.

The quantization layout is particularly important. Each vector is encoded using 9-bit RaBitQ quantization. The code is divided into a 1-bit prefix and an 8-bit suffix. The prefixes remain in DRAM and provide a coarse distance estimator; suffixes and high-precision payload data are stored remotely. Frequently accessed cluster data can additionally be cached on local NVMe SSD.

This arrangement separates two query requirements. Cheap, memory-resident information determines which clusters and vectors are unlikely to contribute to the result. Remote storage is accessed only for candidates that survive this filtering. The design consequently treats quantization not merely as a compression mechanism but as a mechanism for controlling remote I/O.

The paper’s warm-query assumption is material. It assumes that index metadata, including centroids and routing structures, is already resident in memory. Cold starts, in which the compute instance must first retrieve metadata from object storage, are excluded from the primary evaluation. The authors suggest workload-driven prefetching as a possible mitigation, but that mechanism is not implemented or evaluated.

Figure 1

Figure 1: RemoteANN separates DRAM-resident routing metadata from local-cache and cloud-object-storage payloads.

Index construction with QGKMeans

Approximate centroid assignment

IVF construction requires repeated assignment of vectors to centroids, and this becomes expensive when the number of clusters is large. RemoteANN introduces QGKMeans, which uses SymphonyQG as an approximate nearest-centroid accelerator. At each kk-means iteration, QGKMeans builds an ANN structure over the current centroids and searches it with each data vector. The structure is rebuilt after centroid updates.

The resulting approximation is empirically controlled through clustering quality rather than through an exact assignment guarantee. Across the evaluated datasets, QGKMeans produces WCSS and downstream IVF recall comparable to Faiss, SuperKMeans, and SeededANN while reducing construction time. Representative results include:

Dataset QGKMeans time Fastest baseline time QGKMeans recall
SIFT 6.2 s 8.9 s 0.941
MSong 9.2 s 10.1 s 0.992
Contriever 12.9 s 28.2 s 0.977
GIST 15.6 s 23.2 s 0.821
Cohere 204.2 s 1,128.4 s 0.947
Deep-1B 8,973.5 s unavailable within 12 h 0.999

The strongest result is on Cohere, where QGKMeans is approximately 5.5×5.5\times faster than the fastest evaluated baseline while maintaining essentially equivalent clustering quality. On Deep-1B, QGKMeans completes in roughly 2.5 hours, whereas all compared alternatives exceed the stated 12-hour cutoff. The implication is that approximate centroid assignment can make flat IVF construction operationally feasible at large scale, although the evaluation does not establish how QGKMeans behaves under distribution drift or incremental index maintenance.

Inter-cluster locality

Conventional IVF layouts do not require a meaningful physical order among clusters because local random access is relatively cheap. That assumption fails for object storage. If query-selected clusters are scattered through a large object, merging their byte ranges may produce oversized requests containing substantial irrelevant data.

RemoteANN orders clusters according to an approximate minimum-weight Hamiltonian path over centroid distances. It evaluates nearest-neighbor and MST-doubling heuristics, as well as Hilbert and Z-order curves after PCA projection. The nearest-neighbor heuristic produces the shortest empirical centroid path on all six million-scale datasets, despite the MST method having the stronger worst-case approximation guarantee.

The full distance-matrix computation has O(K2d)O(K^2d) cost for KK centroids in dd dimensions. To make the procedure practical for large KK, the implementation recursively partitions centroids and applies localized ordering within each partition. With 262,144 centroids, the partitioned procedure completes in under one minute according to the paper.

Intra-cluster locality

Vectors within each cluster are sorted by distance to the cluster centroid. This ordering is designed for the later range-selection procedure. Under the RaBitQ estimator, vectors farther from the centroid have larger distance-estimation error bounds because the error term is scaled by their centroid-relative norm. Such vectors are therefore harder to prune and tend to remain in the candidate set. Placing them contiguously makes the surviving candidates occupy a smaller physical interval, reducing the byte span of a Range-GET.

Figure 2

Figure 2: Intra-cluster reordering concentrates vectors that survive quantization-based pruning into a smaller physical range.

Query processing

RemoteANN’s query pipeline first selects the top nproben_{\text{probe}} IVF clusters using DRAM-resident centroids. It then estimates vector distances with the 1-bit RaBitQ prefixes, prunes clusters, computes candidate byte ranges, merges compatible requests, and retrieves data from either local NVMe or cloud object storage. Retrieved vectors are reranked using the available higher-precision information.

Analytical cluster pruning

RaBitQ supplies an unbiased distance estimator with a high-probability error bound. For each vector, RemoteANN derives lower and upper distance bounds. Since the exact top-kk distance is unknown before remote retrieval, it uses the 16.1×16.1\times0-th smallest upper bound as a conservative threshold. A cluster is discarded if the lower bound of every vector in that cluster exceeds this threshold.

On the six million-scale datasets, conservative pruning reduces the number of remaining clusters substantially. For example, with 4,096 IVF clusters and OpenAI queries probing 240 clusters, only 13.9 clusters are retrieved on average while preserving a recall of 0.9716. The aggressive estimator-based threshold reduces this to 8.1 clusters with recall 0.9705, a recall loss of less than 0.5 percentage points relative to the conservative configuration.

The conservative mode is therefore the paper’s principal accuracy-preserving mechanism. The aggressive mode exposes an explicit cost-recall trade-off, but it is not theoretically guaranteed to preserve all valid neighbors. The authors also report that fewer than 0.01% of vectors violate the analytical RaBitQ bounds in their workloads; this empirical violation rate supports the observed recall, but it does not replace the probabilistic nature of the bound.

RemoteANN additionally performs dynamic pruning after requests have been dispatched. As completed clusters improve the current top-16.1×16.1\times1 threshold, pending clusters can be abandoned if their bounds become insufficient. This reduces work and straggler impact but cannot reduce object-storage request charges, because the requests have already been issued.

Range optimization

Downloading an entire IVF cluster is wasteful because only a small subset of vectors typically survives the coarse estimator. RemoteANN therefore identifies the minimum contiguous byte interval containing all unpruned vectors in a cluster and issues a Range-GET for that interval.

Range optimization reduces downloaded volume by at least 44% relative to full-cluster retrieval in the reported experiments. Intra-cluster reordering improves the reduction further:

Dataset Random layout Reordered layout
SIFT 55.8% of baseline volume 48.8%
MSong 46.3% 34.1%
Contriever 41.5% 35.4%
GIST 30.7% 19.3%
MXBAI 34.6% 27.4%
OpenAI 22.2% 19.8%

The values are normalized to downloading without range optimization, so the OpenAI result indicates that reordered range retrieval transfers only 19.8% of the corresponding unoptimized volume. This establishes that physical vector ordering is not an auxiliary implementation detail: it directly determines the effectiveness of the remote access primitive.

Request merging

Even after pruning and range selection, issuing one Range-GET per cluster can remain expensive because object-storage pricing is request-oriented. RemoteANN merges nearby ranges subject to a 600 KB maximum request size. A dynamic-programming algorithm sorts ranges by offset and optimizes lexicographically: it first minimizes the number of requests and then minimizes total transferred bytes among solutions with that minimum count.

The 600 KB threshold is empirical and workload-dependent. Larger thresholds can reduce request counts but may increase unnecessary transfer and latency. This parameter thus encodes a cost-latency policy rather than a universally optimal constant.

Figure 3

Figure 3: Nearby byte ranges are consolidated into bounded-size requests to reduce object-storage API operations.

Nearest-neighbor cluster ordering consistently improves merging compared with random placement. For example, at a fixed scan configuration, requests on SIFT fall from 60.3 under random ordering to 25.5 under nearest-neighbor ordering; on MSong they fall from 29.3 to 18.3. The improvement is smaller on high-dimensional OpenAI data, where requests decrease from 236.9 to 218.4, indicating that centroid proximity is an imperfect proxy for query-induced physical locality.

Local NVMe caching

RemoteANN optionally caches hot clusters on local NVMe SSD. The cache uses cluster-level allocation, 4 KB alignment, a preallocated backing file, TinyLFU-style admission, aging-LFU replacement, and asynchronous I/O through io_uring.

Cluster-level caching conflicts with fine-grained range retrieval. To resolve this conflict, the system downloads an optimized range only when it occupies less than a threshold fraction 16.1×16.1\times2 of the cluster; otherwise, it fetches the complete cluster to populate the cache. This design sacrifices some immediate bandwidth efficiency for future cache reuse.

The cache evaluation shows monotonic growth in cluster hit ratio with capacity, but modest absolute coverage for the workloads tested. At 30% cache capacity, the hit ratio reaches 20.1% for Contriever and 13.1% for OpenAI. More importantly, caching does not improve throughput in the reported single-query experiments. Its value is therefore workload-dependent and primarily associated with reducing repeated remote access rather than with a demonstrated universal latency improvement.

Experimental evaluation

End-to-end performance

The evaluation uses SIFT, MSong, Contriever, GIST, MXBAI, and OpenAI at roughly million-vector scale, with additional experiments on 10-million-vector Cohere and the billion-vector Deep-1B dataset. RemoteANN is compared with Lance-RQ, an IVF-RaBitQ object-storage configuration, and RemoteSPANN, a SPANN implementation adapted to the same remote storage backend.

At 97% target recall, RemoteANN has the lowest median latency in all 18 dataset-concurrency configurations and the lowest 95th-percentile latency in 16. Relative to Lance-RQ, median latency improves by factors of 1.47--5.57 and 95th-percentile latency by factors of 1.19--5.15. The exceptions in tail latency occur on MSong at concurrency levels 1 and 4, where RemoteSPANN is slightly better.

Representative median and tail latencies at concurrency 16 are:

Dataset RemoteANN 16.1×16.1\times3 Lance-RQ 16.1×16.1\times4 RemoteANN 16.1×16.1\times5 Lance-RQ 16.1×16.1\times6
SIFT 62.6 ms 314.1 ms 98.4 ms 343.0 ms
MSong 38.6 ms 188.9 ms 63.3 ms 269.5 ms
Contriever 35.3 ms 188.8 ms 54.1 ms 271.2 ms
GIST 118.5 ms 189.1 ms 221.4 ms 272.9 ms
MXBAI 33.5 ms 186.5 ms 51.7 ms 266.3 ms
OpenAI 44.3 ms 191.3 ms 70.4 ms 280.4 ms

The reported QPS-recall curves fluctuate rather than varying smoothly. The paper attributes this behavior to object-storage performance variability, which is consistent with the fact that remote request latency is not fully controlled by the ANN algorithm. This observation qualifies the throughput claims: they are strong under the tested AWS deployment, but cloud-service variability remains part of the end-to-end performance distribution.

Figure 4

Figure 4: RemoteANN maintains a stronger throughput-recall frontier than Lance-RQ and RemoteSPANN across concurrency levels and datasets.

Remote I/O and cost-relevant behavior

RemoteANN issues fewer Range-GET requests than both baselines at 97% recall:

Dataset RemoteANN Lance-RQ RemoteSPANN
SIFT 18.5 97.1 58.5
MSong 10.7 57.6 39.9
Contriever 8.6 57.6 19.9
GIST 41.4 56.4 294.7
MXBAI 6.8 57.1 27.6
OpenAI 12.0 57.7 79.2
Cohere 18.6 26.2 300.0
Deep-1B 146.5 810.2 unavailable

The reduction is especially pronounced on GIST and Deep-1B relative to RemoteSPANN and Lance-RQ, respectively. These results substantiate the paper’s cost argument: throughput improvements are accompanied by fewer billable object-storage operations rather than achieved solely by consuming more remote bandwidth.

Construction time and memory

RemoteANN’s construction time is higher than Lance-RQ’s on every reported dataset because it uses flat rather than hierarchical 16.1×16.1\times7-means and performs additional reordering and layout work. However, it is substantially faster than RemoteSPANN, with a maximum reported construction speedup of 16.1×16.1\times8. On Deep-1B, RemoteANN requires 11,029 seconds compared with 5,176 seconds for Lance-RQ, while RemoteSPANN does not complete within the evaluation boundary.

RemoteANN and Lance-RQ have similar memory footprints because both retain compact quantized routing information, whereas RemoteSPANN requires substantially more memory for routing graphs, centroids, and replicated vector structures. The results demonstrate a deliberate trade-off: RemoteANN accepts additional one-time construction cost to reduce online remote I/O and query latency.

Figure 5

Figure 5: RemoteANN preserves its throughput and request-count advantages on Cohere and Deep-1B, including the billion-vector setting.

Ablation analysis

The ablation study isolates cluster pruning, range optimization, request merging, and caching. Pruning and range optimization provide the primary throughput gains without measurable recall degradation under the conservative threshold. Request merging reduces API operations but can slightly reduce throughput at high concurrency because merging may transfer extra bytes. This result is important because it rejects a simplistic claim that fewer requests always imply lower latency.

The reported request-cost reductions from merging reach approximately 30% on Contriever and 14% on OpenAI. Caching does not alter the measured QPS-recall curves in the selected experiments, although its hit ratio increases with cache capacity.

A raw-vector variant, RemoteANN-Raw, removes quantized remote payloads while retaining the query-side optimizations. It remains faster than both baselines but slower than standard RemoteANN. At concurrency 16, throughput is 305.2 versus 412.5 QPS on Contriever and 199.2 versus 298.2 QPS on OpenAI. This comparison indicates that the principal gains come from the co-designed layout and I/O pipeline, while RaBitQ contributes an additional reduction in payload and candidate-processing cost.

Figure 6

Figure 6: Cluster pruning and range optimization dominate throughput improvements, while request merging primarily reduces API operations and can impose a high-concurrency bandwidth cost.

Limitations and open questions

RemoteANN targets a static IVF index. Incremental insertion, deletion, rebalancing, and consistency under concurrent updates are not addressed. This limitation matters because physically reordered object layouts and cluster-level caching complicate mutation without periodic reconstruction. Systems such as SPFresh explicitly target incremental maintenance [(2610.25172); see also the paper’s discussion of SPFresh], but RemoteANN does not provide a comparable update protocol.

The warm-query assumption excludes metadata cold-start latency. In a serverless or highly bursty deployment, loading centroids and quantized routing metadata may dominate the first-query response time. The paper identifies prefetching as a possible solution but provides no quantitative analysis of its accuracy, resource overhead, or interaction with cache admission.

The empirical study is also tied to a particular AWS configuration, object-store implementation, 600 KB request threshold, 9-bit RaBitQ setting, and static query workloads. The extent to which the same ordering heuristics and threshold remain optimal across providers, regions, request pricing models, filtered queries, or nonstationary workloads remains open. Finally, the pruning guarantee is probabilistic through RaBitQ’s error bound, and the reported violation rate is empirical; stronger workload-independent end-to-end recall guarantees are not established.

Conclusion

RemoteANN presents a coherent cloud-native design for ANN search in which object-storage latency and request pricing are treated as first-class index-design constraints. Its main technical contribution is the integration of IVF, RaBitQ, QGKMeans, inter- and intra-cluster reordering, analytical pruning, range retrieval, request merging, and local caching into a single storage-aware pipeline.

Across the evaluated workloads, this co-design yields lower latency, higher throughput, and substantially fewer remote requests at approximately 97% recall. The strongest evidence supports the claim that physical layout and query-side I/O policy are as important as the underlying ANN approximation method in disaggregated vector search. The remaining central question is whether these techniques can be extended to mutable, cold-start-sensitive workloads without forfeiting the measured performance and cost advantages.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

Explain it Like I'm 14

1. What is the paper about?

The paper introduces RemoteANN, a system for searching through large collections of vectors stored in cloud object storage, such as Amazon S3.

A vector is a list of numbers used to represent things such as images, songs, words, or documents. For example, an image might be converted into a long list of numbers that describes its colors, shapes, and contents.

Vector search finds items that are most similar to a question or example. If you give a system a picture of a cat, vector search might find other pictures that look like cats.

The main problem is that cloud storage is cheap and can hold enormous amounts of data, but it is slower to access than a computer’s memory or local disk. RemoteANN is designed to make vector searches faster and cheaper when the main data is stored in the cloud.

2. What questions does the research investigate?

The paper focuses on several important questions:

  • How can a vector search engine avoid downloading unnecessary data from cloud storage?
  • How can it reduce the number of separate requests sent to the cloud?
  • How can it keep search results accurate while using compressed versions of vectors?
  • How can the system build its search index more quickly?
  • How can stored data be arranged so that related information is located close together?

The researchers want to improve three things at the same time:

  1. Speed — searches should finish quickly.
  2. Cost — fewer cloud storage requests should be needed.
  3. Accuracy — the system should still find almost all of the truly nearest items.

3. How does RemoteANN work?

Organizing vectors into groups

RemoteANN uses an index called IVF, or Inverted File index. Instead of comparing a query with every vector, IVF divides vectors into groups called clusters.

A simple analogy is a library. Rather than searching every book in the library, you first decide which shelves are likely to contain the right book. You then search only those shelves.

Each cluster has a central vector called a centroid. When a query arrives, RemoteANN first checks which centroids are closest to the query. It then focuses on those clusters.

This is especially useful for cloud storage because the system can retrieve a whole group of likely candidates in one general operation, instead of making many small, slow trips over the network.

Compressing vectors with RaBitQ

RemoteANN uses a technique called RaBitQ quantization to make vectors smaller.

Quantization is similar to replacing a detailed photograph with a smaller, lower-quality version. The smaller version takes less space and can be examined more quickly, although it contains less detail.

RemoteANN keeps some very small compressed information in the computer’s memory. It uses this information to estimate which vectors are likely to be useful. The full, accurate vectors remain in cloud storage.

RaBitQ is useful because it also provides an estimate of how much error its compressed distances might have. This helps RemoteANN make safe decisions about which data can be ignored.

Pruning unhelpful clusters

Pruning means removing options that are clearly not useful.

For example, if a teacher asks you to find the five closest houses to your school, you do not need to inspect houses in another country. RemoteANN uses the compressed vector information to identify clusters that are very unlikely to contain good answers.

Those clusters are not downloaded at all. This saves both time and cloud storage request fees.

RemoteANN can also update its decisions while a search is running. If it already has five very good results, it may decide that a slow or distant cluster is no longer worth waiting for.

Downloading only parts of a cluster

Even when a cluster is useful, RemoteANN does not always download the entire cluster.

The vectors inside each cluster are arranged in a special order. This makes the likely useful vectors appear close together in the stored file. RemoteANN can then request only the needed section of the file.

This is called a Range-GET request. It is like asking a library to send pages 50–60 of a book instead of sending the entire book.

This reduces the amount of data transferred through the network.

Combining cloud requests

Cloud storage usually charges by the number of requests, not only by the total amount of data.

Suppose a search needs five nearby pieces of a file. Sending five separate requests may be expensive and slow. If the pieces are close together, RemoteANN combines them into one larger request.

This is called request merging.

To make this work well, the system stores nearby clusters close together in the cloud file. The researchers use a method based on a nearest-neighbor heuristic, which is a practical strategy for arranging objects so that similar ones are next to each other.

Using a local SSD cache

Frequently used clusters can be copied to a fast local NVMe SSD. This acts as a cache, or temporary nearby storage.

If a future query needs a cluster already in the cache, RemoteANN can read it locally instead of downloading it again from the cloud.

This is similar to keeping frequently used books on your desk instead of returning to the library each time.

Building the index faster with QGKMeans

Before searches can be performed efficiently, the system must build the clusters. This usually uses an algorithm called kk-means.

The basic idea of kk-means is:

  1. Choose several temporary cluster centers.
  2. Assign each vector to its nearest center.
  3. Move each center to better represent its assigned vectors.
  4. Repeat the process.

This can take a long time for very large datasets. RemoteANN introduces QGKMeans, which uses a faster approximate search method to find the closest cluster center.

The method does not always find the exact answer during every step, but it produces clusters with almost the same quality much more quickly.

4. What did the researchers find?

The researchers tested RemoteANN on several real-world datasets containing millions of vectors. These datasets represented different types of information, including image-related data, music, text, and language-model embeddings.

The main results were:

  • RemoteANN achieved up to 5.9 times higher search throughput than the comparison systems. In other words, it could handle many more searches in the same amount of time.
  • It issued up to 16.1 times fewer cloud storage requests.
  • It maintained about 97% target recall.

Recall measures how many of the truly best answers the system successfully finds. A recall of 97% means that the system found nearly all of the important nearest neighbors while avoiding much of the unnecessary cloud work.

The separate tests also showed that:

  • QGKMeans built clusters faster than the comparison methods while keeping similar cluster quality.
  • Cluster pruning significantly reduced the number of clusters downloaded.
  • Downloading only selected byte ranges reduced data transfer by at least 44% in the reported experiments.
  • Reordering clusters improved request merging.
  • More aggressive pruning reduced cloud work further, with less than a 0.5 percentage-point loss in recall in the tested settings.

These results matter because cloud object storage has two major disadvantages for this task: network delays and per-request charges. RemoteANN directly targets both problems.

5. Why is this research important?

Many modern applications use vector search. Examples include:

  • Finding similar images
  • Searching documents by meaning
  • Recommending songs or products
  • Helping chatbots find useful information
  • Searching large databases of artificial-intelligence embeddings

These applications may store billions of vectors. Keeping all of them in expensive, fast computer memory can be impractical. Cloud object storage is cheaper and can grow easily, but searching it efficiently is difficult.

RemoteANN shows that the storage system and the search algorithm should be designed together. Simply placing an ordinary vector index on cloud storage does not work well because ordinary indexes often make too many small network requests.

The paper’s main lesson is that careful compression, data arrangement, pruning, request combining, and caching can make cloud-based vector search much more practical.

There are still trade-offs. Local SSDs cost more than basic cloud storage, and aggressive compression or pruning could reduce accuracy in some situations. Also, the experiments mainly study warm searches, where important index information is already loaded into memory. The first search after starting a new computer instance may still be slower.

Overall, RemoteANN could help companies build large-scale search, recommendation, and artificial-intelligence systems that are faster, cheaper, and more scalable while storing most of their data in the cloud.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

  • Cold-start performance remains unresolved. The evaluation explicitly restricts attention to warm queries, while compute-instance startup, metadata loading, cache population, and the first-query latency are left unmeasured.
  • The proposed prefetching idea is not evaluated. The paper suggests using user interaction signals to hide cold-start latency, but does not specify or assess the required prediction accuracy, prefetch overhead, stale-prefetch cost, or behavior under inaccurate signals.
  • Cache behavior and policy are underspecified. The local NVMe cache section is incomplete, and the paper does not establish a cache admission, eviction, consistency, or prefetch policy, nor quantify hit rates and end-to-end benefits under different cache capacities.
  • The cost-benefit trade-off of local NVMe caching is not fully characterized. The additional price of NVMe-equipped instances, cache persistence across instance failures, operational management costs, and the break-even point relative to object-storage request savings remain unknown.
  • The system’s behavior under dynamic updates is unexplored. The paper does not evaluate vector insertion, deletion, replacement, or update workloads, although these operations could invalidate centroids, reorderings, quantization metadata, cached clusters, and byte-range offsets.
  • Index maintenance costs are not reported. It remains unclear how much time, network traffic, and object-storage cost are required to rebuild or incrementally maintain the IVF index after data changes.
  • The evaluation does not establish performance under realistic mixed workloads. The experiments appear focused on ANN queries, without measuring interactions among searches, updates, bulk ingestion, index construction, cache warming, and metadata maintenance.
  • Concurrency scalability is insufficiently established. The paper does not report throughput, tail latency, request amplification, or bandwidth utilization across increasing numbers of simultaneous queries and compute instances.
  • Object-storage throttling and rate limits are not evaluated. The system’s behavior under request throttling, burst limits, transient failures, retries, and provider-side congestion remains unknown.
  • Tail latency and straggler sensitivity require deeper analysis. Dynamic pruning can avoid processing some in-flight clusters but cannot undo already issued requests; the impact of remote-storage stragglers on p95/p99 latency is not quantified.
  • Failure recovery and fault tolerance are not addressed. The paper does not explain how RemoteANN handles failed Range-GET requests, partial responses, corrupted objects, unavailable NVMe caches, compute-node failures, or inconsistent metadata.
  • Consistency guarantees are unspecified. The relationship between object-storage payloads, DRAM-resident metadata, local SSD contents, and concurrent index updates is not defined.
  • Generalization across object-storage providers is uncertain. Results are not compared across Amazon S3, Azure Blob Storage, Google Cloud Storage, or other services with different latency distributions, Range-GET semantics, minimum billing units, pricing, and throughput limits.
  • The cost model is incomplete. The paper emphasizes request counts but does not provide a comprehensive accounting of data-transfer charges, compute-instance costs, SSD costs, metadata operations, retries, and cross-region or cross-zone traffic.
  • The choice of a fixed 600 KB request-merging threshold is not sufficiently justified. The threshold is selected empirically, but sensitivity to object-store provider, network conditions, query concurrency, payload size, and latency-versus-cost objectives is not reported.
  • The request-merging objective may not match real operating costs. The dynamic program minimizes request count first and downloaded bytes second, but does not optimize provider-specific billing tiers, latency, bandwidth contention, or tail latency jointly.
  • The optimality claim for request merging is limited in scope. The dynamic-programming formulation assumes sorted, consecutive request groups and a fixed threshold; it does not establish optimality when nonconsecutive ranges, parallelism limits, variable request costs, or adaptive thresholds are allowed.
  • The effectiveness of inter-cluster ordering under workload shift is unknown. Reordering is based only on centroid geometry and ignores query frequencies, temporal locality, tenant-specific distributions, and changing workloads.
  • The partitioned nearest-neighbor reordering lacks quality analysis. Although partitioning reduces the O(n2d)O(n^2d) cost, the paper does not quantify how much it degrades global locality or request-merging effectiveness relative to the unpartitioned heuristic.
  • The relationship between Hamiltonian path length and actual query I/O is only empirically suggested. The paper does not provide a formal bound or broader validation showing that this proxy reliably predicts merged-request counts, bytes transferred, latency, or cost.
  • High-dimensional and highly nonuniform centroid geometries are insufficiently studied. The reordering methods are evaluated on selected datasets, but their robustness to anisotropic, clustered, manifold, or poorly separated centroid distributions remains uncertain.
  • Intra-cluster reordering may impose undesirable trade-offs. Sorting vectors by centroid distance could affect compression locality, parallel decoding, update efficiency, and other query layouts, but these effects are not evaluated.
  • The range-optimization mechanism may still retrieve large spans for scattered candidates. The paper does not quantify worst-case or distribution-dependent behavior when unpruned vectors are dispersed within a cluster.
  • The interaction between range optimization and object-storage billing granularity is unresolved. Downloading a narrow byte range may reduce transferred bytes but not necessarily reduce billed request or minimum-object-range costs; provider-specific implications are not analyzed.
  • The theoretical pruning guarantees are probabilistic but operational guarantees are not established. The reported bound-violation rate is below 0.01% empirically, yet the paper does not provide a formal end-to-end recall guarantee under repeated queries, distribution shift, or adversarial vectors.
  • The impact of RaBitQ bit allocation is underexplored. The system uses a 9-bit representation and mentions lower-bit configurations, but does not characterize the accuracy, memory, request, bandwidth, and latency trade-offs across bit widths.
  • The memory footprint of the routing index is not reported. For billion-scale datasets, the storage requirements for centroids, 1-bit prefixes, metadata, offsets, and auxiliary structures may be substantial, but scalability limits are not quantified.
  • The choice of IVF parameters is not systematically optimized. The effects of the number of clusters, nproben_\text{probe}, cluster-size skew, and target kk on accuracy, memory, request count, bytes transferred, and construction time are not comprehensively studied.
  • Cluster-size imbalance is not addressed. Large or highly skewed clusters could undermine range efficiency, request merging, cache granularity, and query load balancing, but no imbalance mitigation is described.
  • QGKMeans scalability and convergence behavior remain uncertain. The evaluation fixes 25 iterations and selected cluster counts; it does not analyze convergence speed, sensitivity to initialization, iteration count, dimensionality, centroid count, or memory bandwidth.
  • QGKMeans is not compared under production-scale clustering configurations. Sampling, hierarchical clustering, and other accelerations are disabled for fairness, so its performance relative to complete practical indexing pipelines remains unknown.
  • The quality impact of approximate centroid assignment is incompletely characterized. Similar WCSS and recall are reported for selected settings, but the effects on downstream pruning, range selection, request merging, and final recall are not isolated.
  • The baseline comparison is limited. The paper does not comprehensively compare against optimized cloud-native systems, graph-based remote indexes, product-quantization variants, or provider-native vector search services under matched infrastructure and cost conditions.
  • The reported speedups may depend on favorable experimental settings. The paper does not fully disclose or vary object sizes, network topology, instance types, storage-region placement, connection pooling, parallel request limits, or storage-service configuration.
  • Accuracy is evaluated primarily around a 97% target recall. Behavior at substantially higher recall, lower recall, different values of kk, and alternative metrics such as recall@1, recall@100, NDCG, or maximum error remains unclear.
  • Query-distribution coverage is limited. The paper uses designated real-world query workloads but does not test out-of-distribution queries, adversarial queries, skewed popularity distributions, repeated queries, or workload changes over time.
  • The system’s support for distance metrics beyond Euclidean distance is unclear. The reordering, RaBitQ transformation, pruning bounds, and cluster-ordering objective are presented for Euclidean distance, leaving cosine, inner-product, and other metrics unresolved.
  • Non-vector payloads and filtering constraints are not considered. The effects of metadata predicates, tenant isolation, attribute filtering, deletions, and hybrid scalar-plus-vector queries on pruning and contiguous range retrieval are unknown.
  • The storage layout’s durability and versioning strategy is unspecified. The paper does not explain how reordered objects, metadata, quantization parameters, and cache contents are atomically published or rolled back during index replacement.
  • Energy and environmental costs are not measured. The trade-off between reduced network traffic and increased CPU work for quantization, pruning, sorting, merging, and cache management remains unquantified.
  • The paper does not provide a complete end-to-end reproducibility account. Detailed hardware, object-storage configuration, network conditions, implementation settings, query concurrency, and cost assumptions needed to reproduce the reported results are not fully presented in the supplied text.

Practical Applications

Immediate Applications

  • Cost-efficient vector databases for cloud-hosted AI applications (software, cloud infrastructure, generative AI) Deploy RemoteANN-style indexing for semantic search over documents, images, audio, product catalogs, and embeddings stored in Amazon S3, Azure Blob Storage, Google Cloud Storage, or comparable services. The combination of IVF, RaBitQ-based pruning, Range-GET operations, request merging, and NVMe caching can reduce remote-storage requests and network traffic while maintaining approximately 97% target recall. Potential products/workflows: managed vector databases, retrieval-augmented generation (RAG) backends, embedding search APIs, and serverless similarity-search services. Dependencies: compute and object storage should generally be co-located within the same cloud region; otherwise, inter-region transfer charges may outweigh request-cost savings. Performance also depends on a warm compute instance and sufficient DRAM for centroids and quantized metadata.
  • Lower-cost retrieval for RAG and conversational agents (generative AI, enterprise search) Use the in-memory RaBitQ codes to eliminate clusters and vectors that are unlikely to contribute to a prompt’s top-kk results before downloading full-precision embeddings. This is directly applicable to document retrieval, code search, customer-support assistants, and internal knowledge bases. The paper specifically suggests using early user interaction signals—such as typing in a conversational interface—to prefetch index metadata and hide cold-start latency. Dependencies: recall requirements must tolerate approximate search; workloads with highly repetitive or geographically localized access patterns benefit most from caching and prefetching.
  • Scalable multimedia and recommendation search (e-commerce, media, advertising, social platforms) Store large image, video, music, or product-embedding collections in object storage while keeping compact routing metadata on compute nodes. Inter-cluster reordering can improve request merging, and intra-cluster ordering can reduce the byte ranges downloaded for candidate evaluation. Potential tools: image-nearest-neighbor search, duplicate-media detection, “similar products” recommendation, music discovery, and content moderation candidate retrieval. Dependencies: the embedding distribution should be sufficiently compatible with IVF clustering; highly dynamic datasets may require frequent re-indexing and data reordering.
  • Serverless or elastically scaled vector-search services (cloud software, databases) Adopt the three-tier layout described in the paper: DRAM for centroids and compact codes, local NVMe for hot data, and object storage for primary vectors. This allows compute instances to scale up or down independently of the underlying data store. Benefits: reduced local-disk capacity requirements, easier data durability management, and potentially lower costs for workloads with variable demand. Dependencies: cold-start behavior remains a major issue. Metadata prefetching, instance warm pools, or persistent memory may be needed for interactive latency.
  • Faster construction and refresh of IVF indexes (data engineering, ML infrastructure) Integrate QGKMeans into existing indexing pipelines to accelerate centroid assignment during kk-means construction. The evaluation reports comparable clustering quality and downstream recall, with construction speedups over the fastest baseline ranging from approximately 1.4×1.4\times to 5.5×5.5\times on the reported datasets. Potential workflows: nightly embedding-index refreshes, incremental content ingestion pipelines, and rapid re-indexing after model or embedding-version changes. Dependencies: QGKMeans relies on an approximate nearest-neighbor accelerator for centroid assignment. Its behavior should be revalidated for new vector distributions, cluster counts, and distance metrics.
  • Reduction of object-storage API expenditure (cloud FinOps, infrastructure operations) Apply request merging and cluster reordering to reduce the number of discrete GET or Range-GET operations. The paper reports up to a 16.1×16.1\times reduction in object-storage requests relative to representative baselines. Potential operational tool: a cost-aware query planner that chooses the merging threshold based on request price, bandwidth price, latency objectives, and recall targets. Dependencies: the optimal merge threshold is workload- and provider-dependent. The reported 600 KB threshold is an empirical setting, not a universal configuration.
  • Local NVMe caching of frequently accessed vector clusters (cloud infrastructure, database acceleration) Cache hot IVF clusters on compute-local NVMe storage so repeated searches bypass remote object storage. This is useful for popular products, frequently retrieved documents, common support questions, or recurring recommendation queries. Dependencies: local NVMe instances may cost more than general-purpose instances; the savings depend on cache hit rate, eviction policy, dataset popularity skew, and the relative prices of storage requests and compute.
  • Research and teaching infrastructure for cloud-native approximate search (academia and systems education) Use RemoteANN as a reproducible design pattern for studying disaggregated databases, approximate query processing, quantization, remote I/O, caching, and storage-cost-aware indexing. Researchers can independently evaluate pruning, range retrieval, request merging, and caching as modular components. Dependencies: meaningful comparisons require reporting not only recall and latency but also request counts, transferred bytes, cache hit rates, and cloud-provider pricing.
  • Cloud procurement and architecture guidance for vector workloads (policy, IT governance, enterprise architecture) Organizations can use the paper’s findings to distinguish storage cost from API-request cost when selecting cloud services. Vector workloads should be benchmarked under realistic request pricing, time-to-first-byte latency, regional placement, and egress policies rather than evaluated solely by raw storage capacity. Dependencies: pricing models and service-level characteristics vary across providers and change over time; deployment decisions require current provider-specific measurements.

Long-Term Applications

  • Autonomous cost–latency–recall optimization for vector queries (databases, cloud orchestration) Extend RemoteANN with an adaptive controller that selects the number of probed clusters, pruning threshold, merge size, cache policy, and quantization precision per query. A latency-sensitive application could use conservative pruning, while a batch workload could favor aggressive merging and larger downloads. Research needed: robust online optimization under changing query distributions, explicit cloud pricing models, and formal guarantees for recall and tail latency.
  • Dynamic and continuously updated cloud vector indexes (real-time analytics, recommendation, monitoring) Develop update-aware versions of the data layout so newly inserted or modified vectors can be incorporated without repeatedly rebuilding and globally reordering the entire object. This would support news feeds, fraud signals, inventory systems, and real-time personalization. Dependencies: append-only fragments, background compaction, cluster migration, and cache invalidation mechanisms are required. Frequent updates may reduce the locality benefits demonstrated for relatively stable indexes.
  • Multi-tenant vector search with isolation and fairness guarantees (SaaS, enterprise cloud platforms) Use RemoteANN-like layouts in a shared service where multiple customers’ embeddings reside in object storage. Query-aware scheduling could merge requests across compatible workloads while enforcing tenant-level latency, bandwidth, privacy, and cost limits. Research needed: secure physical layouts, encryption-compatible pruning, noisy-neighbor mitigation, tenant-specific caching, and protection against access-pattern leakage.
  • Privacy-preserving and regulated-domain retrieval (healthcare, finance, government) Adapt the architecture for medical-record retrieval, clinical literature search, financial document analysis, or public-sector case management. Compact codes could reduce the amount of sensitive data transferred from storage, while full vectors remain in controlled storage. Dependencies: quantized codes and access patterns may themselves reveal information. Deployment would require encryption, access control, auditability, data residency compliance, and validation that approximate retrieval does not omit safety-critical records.
  • Hardware-aware extensions beyond NVMe (computer architecture, robotics, edge AI) Map the three-tier design onto persistent memory, computational storage, GPUs, smart network interfaces, or edge gateways. For robots or autonomous systems, local caching could hold frequently used visual or spatial clusters while the cloud stores the complete corpus. Research needed: energy-aware scheduling, intermittent connectivity handling, synchronization between edge caches and object storage, and guarantees under delayed or unavailable network access.
  • Learned physical layouts based on real query workloads (database optimization, machine learning systems) Replace centroid-only nearest-neighbor ordering with a workload-aware layout learned from historical query co-occurrence. Clusters frequently selected together could be placed in the same object ranges, potentially improving merging beyond the geometric heuristic. Dependencies: query logs must be representative and privacy-compliant. Workload shifts could make a learned layout obsolete, requiring monitoring and periodic reorganization.
  • Stronger guarantees for pruning and approximate retrieval (theory, safety-critical search) Extend the RaBitQ-based bounds into end-to-end probabilistic guarantees that account for quantization error, cluster selection, range truncation, asynchronous pruning, and cache state. Such guarantees could support applications that need explicit recall or confidence contracts. Research needed: formal composition of error probabilities, robustness under non-Euclidean or learned metrics, and validation on distributions substantially different from the reported datasets.
  • Energy- and carbon-aware vector retrieval (sustainability, large-scale AI) Use the reductions in network transfers and object-storage operations to lower energy consumption for large embedding workloads. A scheduler could choose between remote retrieval, local cache access, additional compute for pruning, or delayed batch processing based on carbon intensity and service objectives. Dependencies: energy savings are not directly measured in the paper and must be established through end-to-end instrumentation. Additional CPU work for quantization and pruning could offset network savings in some workloads.
  • Vector search over heterogeneous and non-Euclidean embeddings (scientific computing, knowledge graphs, robotics) Generalize the design to cosine, inner-product, binary, multimodal, graph, or manifold-based representations. This could enable cloud-native search over scientific simulations, geospatial data, 3D scenes, and embodied-agent memories. Research needed: compatible quantization error bounds, clustering methods, and byte-layout strategies for metrics where the assumptions behind Euclidean IVF and RaBitQ do not directly apply.
  • Policy standards and benchmarking for cloud-native vector databases (industry standards, academia, public policy) Establish benchmark suites that report recall, throughput, tail latency, remote-request count, transferred bytes, cold-start delay, cache hit rate, and total cost of ownership. Such standards would make cloud vector-search products more comparable and help institutions evaluate vendor claims. Dependencies: benchmarks should include realistic update rates, multi-tenant contention, regional pricing, privacy constraints, and diverse workloads rather than relying only on static public datasets.

Glossary

  • Approximate nearest neighbor (ANN) search: A search technique that efficiently finds vectors close to a query without guaranteeing the exact nearest neighbors. “approximate nearest neighbor (ANN) search engines”
  • Centroid: The representative center point of a cluster, typically computed as the mean of its member vectors. “the IVF cluster centroids”
  • Cluster pruning: The removal of clusters that cannot contain sufficiently close nearest-neighbor candidates. “We formalize this process as cluster pruning”
  • Cold-start penalty: The initial latency incurred when a system must initialize resources and retrieve data before serving its first query. “which results in a severe cold-start penalty with prohibitive initial query latency”
  • Coarse-grained distance estimator: An approximate distance-computation mechanism used to eliminate unlikely candidates before exact processing. “serving as a coarse-grained distance estimator”
  • Curse of dimensionality: The degradation of computational and indexing methods as the number of data dimensions increases. “As space-filling curves suffer from the curse of dimensionality”
  • Data locality: The organization of related data in nearby physical storage locations to reduce access costs. “inter-cluster and intra-cluster data reordering improve physical locality”
  • Disaggregated storage-compute architecture: A system design that separates computation from persistent storage resources. “These systems typically adopt a disaggregated storage-compute architecture”
  • Distance estimator: A method for approximating the distance between vectors, often using compressed representations. “RaBitQ provides an unbiased estimator with a theoretical error bound”
  • Dynamic programming: An optimization technique that solves a problem by combining solutions to overlapping subproblems. “We design a dynamic programming (DP) algorithm to merge the requests under a fixed threshold”
  • Euclidean distance: The straight-line distance between points in a multidimensional space. “each edge is weighted by the Euclidean distance between the corresponding centroids”
  • Fine-grained range optimization: A technique that retrieves only the specific byte interval containing potentially useful data. “fine-grained range optimization”
  • Hamiltonian path: A path in a graph that visits every vertex exactly once. “We formulate this objective as a minimum-weight Hamiltonian path problem”
  • Hierarchical clustering: A clustering method that recursively organizes data into a tree of nested groups. “We disable data sampling and hierarchical clustering”
  • Hilbert curve: A space-filling curve used to map multidimensional points into a one-dimensional ordering while attempting to preserve locality. “we evaluate space-filling curves, specifically the Hilbert and Z-order curves”
  • HNSW: A graph-based approximate nearest-neighbor index based on a hierarchy of navigable small-world graphs. “SeededANN represents an HNSW-based approach to accelerating centroid assignment”
  • In-flight request: A storage or network request that has been issued but whose response has not yet arrived. “the remaining in-flight requests”
  • Inner product: The scalar product of two vectors, used here as an equivalent component in distance estimation. “an estimation of the inner product of two normalized vectors”
  • Inverted File (IVF) index: An index that partitions vectors into clusters and searches only selected clusters for a query. “RemoteANN couples an Inverted File (IVF) index with RaBitQ quantization”
  • Johnson–Lindenstrauss Transformation: A randomized projection that approximately preserves pairwise distances while reducing dimensionality. “the codebook is randomly rotated via Johnson-Lindenstrauss Transformation”
  • k-means clustering: An iterative algorithm that partitions data into kk groups by repeatedly assigning points to centroids and updating those centroids. “partitioning the dataset via the kk-means clustering algorithm”
  • Locality-preserving ordering: An arrangement of data intended to place items likely to be accessed together near one another in storage. “we seek an ordering that minimizes the sum of distances between the centroids of consecutive clusters”
  • MST-doubling algorithm: An approximation algorithm for constructing a near-shortest path by doubling the edges of a minimum spanning tree. “the MST-doubling algorithm, which provides a 2-approximation”
  • Minimum spanning tree (MST): A tree connecting all vertices of a weighted graph with minimum possible total edge weight. “the MST-doubling algorithm”
  • Nearest-neighbor heuristic: A greedy algorithm that repeatedly selects the closest unvisited point. “the nearest-neighbor heuristic, which provides an O(log⁡n)O(\log n) worst-case approximation”
  • NVMe SSD: A high-performance solid-state drive using the Non-Volatile Memory Express protocol. “a local NVMe SSD caching layer that bypasses remote I/O”
  • Principal Component Analysis (PCA): A dimensionality-reduction method that projects data onto directions of greatest variance. “a dimensionality reduction by Principal Component Analysis (PCA)”
  • Quantization: The conversion of high-dimensional or high-precision values into compact, lower-bit representations. “quantization constitutes a class of techniques designed to compress high-dimensional vectors into compact, low-bit quantization codes”
  • RaBitQ: A theoretically supported vector-quantization framework that uses compact codes for distance estimation with error bounds. “we leverage the RaBitQ quantization”
  • Recall: The fraction of true nearest neighbors successfully returned by a search system. “at 97\% target recall”
  • Range-GET request: An object-storage request that retrieves only a specified byte interval of an object. “issuing discrete Range-GET requests for every target cluster”
  • Request merging: The consolidation of multiple nearby storage requests into a single larger request. “We call this the request merging strategy”
  • Spatial locality: The tendency of related or jointly accessed data to be stored near one another. “if the target clusters for a given query exhibit poor spatial locality”
  • Space-filling curve: A curve or ordering that maps multidimensional data into one dimension while preserving spatial proximity approximately. “we evaluate space-filling curves”
  • Straggler: A delayed computation or network operation that slows completion of a distributed task. “it improves end-to-end query throughput by dropping some network stragglers”
  • Time-to-first-byte (TTFB): The delay between sending a request and receiving the first byte of its response. “data retrieval from cloud object stores incurs substantial time-to-first-byte (TTFB) network latency”
  • Top-kk search: The retrieval of the kk highest-ranked or nearest results for a query. “the final top-kk ANN results”
  • Unbiased estimator: An estimator whose expected value equals the quantity being estimated. “the RaBitQ estimator provides an unbiased estimation”
  • Vector payload: The primary high-dimensional vector data stored and retrieved by the search system. “persisting the primary vector payload in object stores”
  • Within-Cluster Sum of Squares (WCSS): The sum of squared distances between data points and the centroids of their assigned clusters. “we measure total clustering time, Within-Cluster Sum of Squares (WCSS), and downstream IVF recall”
  • Z-order curve: A multidimensional ordering formed by interleaving coordinate bits to preserve locality approximately. “the Hilbert and Z-order curves”

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Tweets

Sign up for free to view the 1 tweet with 317 likes about this paper.