RemoteANN: A Native Vector Search Engine for Cloud Object Storage
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 throughput speedup while issuing up to fewer object storage requests at 97% target recall.
Paper Prompts
Sign up for free to create and run prompts on this paper.
Top Community Prompts
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:
- Speed — searches should finish quickly.
- Cost — fewer cloud storage requests should be needed.
- 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 -means.
The basic idea of -means is:
- Choose several temporary cluster centers.
- Assign each vector to its nearest center.
- Move each center to better represent its assigned vectors.
- 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 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, , cluster-size skew, and target 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 , 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- 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 -means construction. The evaluation reports comparable clustering quality and downstream recall, with construction speedups over the fastest baseline ranging from approximately to 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
GETorRange-GEToperations. The paper reports up to a 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 groups by repeatedly assigning points to centroids and updating those centroids. “partitioning the dataset via the -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 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- search: The retrieval of the highest-ranked or nearest results for a query. “the final top- 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”





