Pith. sign in

REVIEW 4 major objections 6 minor 50 references

Cost-Effective, Low Latency Vector Search with Azure Cosmos DB

T0 review · 4 major / 6 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A general-purpose operational database can host state-of-the-art vector search, the paper argues, by embedding DiskANN's graph index directly inside Cosmos DB's Bw-Tree, eliminating the need to replicate data to a specialized vector store.

desk verdict A serious systems paper with a plausible core design and real measured results, but the headline 43x/12x cost claim rests on an unmeasured competitor comparison and should be treated as unproven. read the letter →

arxiv 2505.05885 v2 pith:VSY4EZHR submitted 2025-05-09 cs.DB cs.IR

Nitish Upreti , Harsha Vardhan Simhadri , Hari Sudan Sundar , Krishnan Sundaram , Samer Boshra , Balachandar Perumalswamy , Shivam Atri , Martin Chisholm
show 28 more authors
Revti Raman Singh Greg Yang Tamara Hass Nitesh Dudhey Subramanyam Pattipaka Mark Hildebrand Magdalen Manohar Jack Moffitt Haiyang Xu Naren Datha Suryansh Gupta Ravishankar Krishnaswamy Prashant Gupta Abhishek Sahu Hemeswari Varada Sudhanshu Barthwal Ritika Mor James Codella Shaun Cooper Kevin Pilch Simon Moreno Aayush Kataria Santosh Kulkarni Neil Deshpande Amar Sagare Dinesh Billa Zishan Fu Vipul Vishal
This is my paper · ORCID
classification cs.DBcs.IR
keywords vectorsearchapproximatenearestneighborDiskANNAzureCosmosDBoperationaldatabaseBw-Treeserverlessquerycost
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that a general-purpose, cloud-native operational database can deliver vector search on par with specialized vector databases, removing the need to replicate data out of the operational store. To prove this, the authors integrate DiskANN, a graph-based approximate nearest-neighbor library, directly into Azure Cosmos DB NoSQL by storing the index's quantized vectors and adjacency lists as terms inside Cosmos DB's own Bw-Tree index. They report under 20 ms p50 latency for searches over 10 million 768-dimensional vectors at 94.64% recall@10, stable recall across long insert/delete sequences, and roughly 43x and 12x lower per-query cost than Pinecone and Zilliz enterprise serverless offerings, with scale-out to billions of vectors. A sympathetic reader would care because, if true, it means applications can get semantic search, transactions, high availability, and multi-tenancy from one database instead of a separate vector engine.

What carries the argument

The load-bearing mechanism is a rewritten, layout-agnostic DiskANN library exposed through Provider traits, with Cosmos DB's Bw-Tree supplying persistence: quantized vectors are stored as inverted terms keyed by document id, and graph adjacency lists as new forward terms supporting blind incremental updates. Greedy graph search runs over cached quantized vectors, with a small full-precision rerank at the end; a beta-biased distance scaling (Algorithm 7) makes search filter-aware, paginated search handles hybrid predicate queries, mini-batch inserts avoid Bw-Tree duplicate-key constraints, and in-place delete (Algorithm 6) keeps recall stable under updates.

What would settle it

Run the same 10-million-vector, 768-dimensional Wiki-Cohere queries against Pinecone and Zilliz serverless at their listed prices, measure recall@10 at comparable search settings, and compare per-1M-query cost; if either matches 94.64% recall at lower cost, the 43x and 12x claims fail.

Watch

Extended reading notes

Core claim

The central claim is that a state-of-the-art vector index can be built inside an operational database by decoupling the index algorithm from the index layout: the DiskANN graph is rewritten so that its quantized vector terms and adjacency lists live in the database's existing Bw-Tree index and are updated durably and incrementally with each document change. This yields one DiskANN index per replica that is always in sync with the underlying documents, no separate index rebuilds or segment merges, and memory use low enough to cache only quantized terms while full-precision vectors are read from storage only for a small rerank set. The measured consequence is sub-20 ms p50 latency over 10 million vectors, query cost that grows less than 2x for a 100x increase in index size, stable recall under streaming updates (up to 20 points better than drop-only deletes on distribution-shift runbooks), roughly 43x and 12x lower query cost than Pinecone and Zilliz serverless enterprise tiers, and the ability to shard the index per tenant.

Load-bearing premise

The headline cost advantage rests on the assumption that the published prices for Pinecone, Zilliz, and DataStax correspond to setups whose recall and index settings match the 94.64% recall@10 that Cosmos DB was measured at, since the paper does not measure the competitors' recall.

Editorial extensions

If this is right

  • Operational databases can replace the replicate-to-a-vector-DB pattern: applications keep one primary store with transactions, availability, and security SLAs, and still get approximate vector search at the same store.
  • Query cost scales logarithmically with partition size and linearly with partition count, so users control cost by packing vectors into as few partitions as possible.
  • Filter-aware search gives comparable recall to post-filtering at a fraction of the tail latency when predicates are not highly selective.
  • Sharded DiskANN indices make per-tenant vector search in multi-tenant collections faster and more accurate for tenant-scoped queries.
  • If the cost comparisons hold, the reported price gaps imply specialized serverless vector databases are priced for convenience rather than for raw query efficiency.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The cost comparison treats published price lists as proxies for total cost; a fair head-to-head would need identical recall targets and index configurations, so the reported 43x and 12x ratios likely bracket a range rather than a single point estimate.
  • The design suggests a general template: any database with a sufficiently fast, latch-free persistent index and resource governance could host a stateless DiskANN, so the same integration could be replicated in other operational stores.
  • Because the graph is stored as ordinary index terms, vector search inherits the database's backup, replication, and failover story for free, a property that specialized vector engines have to build separately.
  • One testable extension is whether the economics shift for smaller indexes or lower recall targets, where the per-partition fixed costs of the graph index may dominate the quantized-flat fallback.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper presents the design and evaluation of a vector search capability integrated into Azure Cosmos DB NoSQL. The authors rewrite the DiskANN library to decouple its algorithms from physical index layout, store quantized vectors and graph adjacency lists as Bw-Tree index terms, and support querying, incremental updates, deletions, filtered search, and sharded multi-tenant indices through this integrated design. The evaluation uses Wiki-Cohere, MS Turing, and YFCC datasets at scales from 100K to 1 billion vectors, reporting latency, request-unit cost, recall, ingestion throughput, and recall stability under update runbooks. The central claims, stated in the abstract and introduction, are that the system supports under 20 ms query latency over 10 million vectors, maintains stable recall over updates, scales out to billions of vectors, and offers approximately 43x and 12x lower query cost than Pinecone and Zilliz serverless enterprise products.

Significance. If the cost and latency claims held at the stated operating points, this paper would be an important data point in the debate over specialized vector databases: it would demonstrate that a general-purpose operational database can provide high-quality approximate vector search with the availability, durability, and multi-tenancy of an existing cloud database, without replicating data to a separate system. The engineering contributions are real and clearly described: the provider-trait redesign of DiskANN, the use of Bw-Tree forward and inverted terms for index persistence, the asynchronous Rust/C++ interoperability layer, and the paginated and filter-aware search adaptations. The publication of an open-source scenario suite and reliance on independently published DiskANN algorithms are also strengths, and the latency and recall measurements at 10-million-vector scale are plausible and useful.

major comments (4)
  1. [4.1, Table 1] Table 1 is the sole evidence for the abstract's claim of approximately 43x and 12x lower query cost versus Pinecone and Zilliz. The Cosmos DB column uses the measured p99 value of 70 RU per query at searchListSize=100 (recall@10=94.64). The Pinecone and Zilliz columns (32 Read Units and 55 vCUs) are taken from published pricing documentation, not from measurements on those systems; no recall, index configuration, search-list size, or query workload is reported for them. The comparison therefore assumes, without evidence, that those list-price consumption units correspond to a system configuration achieving recall and result quality comparable to Cosmos DB's measured 94.64% recall@10. If a competitor achieves the same recall at a lower unit consumption, the 43x/12x ratios change materially. Because the cost-effectiveness thesis rests on these ratios, this is a load-bearing gap in the evaluation.
  2. [Abstract; Figure 6] The abstract states that the system 'supports <20ms query latency over an index spanning 10 million vectors,' but Figure 6 shows that at L=50 the p50 latency is 13.4ms and p95 is 17.6ms, while p99 is 20.6ms; the <20ms statement is therefore true only for p50/p95, not p99, and only at the L=50 operating point. The cost comparison in Table 1 uses a different operating point: p99 RU at L=100 (70 RU, recall@10=94.64). No single measured configuration delivers both the <20ms latency claim and the 12x/43x cost claim simultaneously. The abstract and introduction should either tie each claim to its operating point and percentile, or the claims should be softened accordingly.
  3. [Section 4 (Figures 6-10)] The latency and RU figures report p50/p95/p99 from what appears to be a single batch of 5000 queries, with no number of repeated runs, confidence intervals, or run-to-run variance. The cost arithmetic in Table 1 treats 70 RU per query as an exact input, but the underlying measurement is a point estimate. Given that the paper's headline claims are quantitative to two significant figures (43x, 12x, <20ms), the absence of error bars or a statement that these are single-run observations leaves the precision of the claims unverifiable. At minimum, state the experimental protocol (number of runs, warmup, cache state) and report variance or confidence intervals for the key operating points.
  4. [Section 4.4, Table 2; Section 1] The introduction highlights that ingestion 'offers cost and performance comparable to other vector databases,' but Table 2 shows Cosmos DB insertion cost is 5.4x higher than Zilliz (and only 33%/53% lower than Pinecone/DataStax) using the same unmeasured list-price methodology as Table 1. The text's suggestion that autoscale discounts reduce this gap is not part of Table 2 and no measured autoscale price is provided. The 'cost-effective' claim for write-heavy workloads is therefore not established, and the comparison should be either measured on equivalent configurations or explicitly labeled as a list-price comparison under stated assumptions.
minor comments (6)
  1. [Figure 6] The last legend entry reads 'L Search=20, Recall=97.15'; from the monotonic recall trend this should be L=200.
  2. [Section 3.5] The phrase 'If the selectivity is low, i.ei, at least 5000 documents' contains a typo: 'i.ei' should be 'i.e.'.
  3. [Section 4.2] The sentence 'the query planner sends queries invokes the DiskANN index' is missing a conjunction and should read 'sends queries and invokes the DiskANN index'.
  4. [Section 2.1] The phrase 'Recall k@k' should be 'Recall@k' or 'k-recall@k' for consistency with the rest of the paper.
  5. [Section 4, Configuration] The configuration paragraph says 'We use the the following parameters' with a duplicated 'the'; please fix.
  6. [Table 1] The table header says 'P99 vector search query and monthly storage costs'; the caption should also state that Cosmos DB's 70 RU is the p99 value at L=100 and that the competitor columns are list-price documentation values, not measured results.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: measured RUs and published prices, not fitted inputs; DiskANN citations are independently published.

full rationale

The paper's derivation chain is self-contained. Query latency and RU charges are measured directly from the implemented system (Section 4.1, Figure 6), and competitor costs are computed by arithmetic on publicly listed prices (Table 1); no parameter is fitted to a subset of data and then presented as a prediction. The central algorithmic components—DiskANN greedy search, insert, RobustPrune, in-place delete, and beta-biased filter search—are either specified in the paper's own pseudocode (Algorithms 1–7) or cited to independently published, externally benchmarked prior work (e.g., DiskANN NeurIPS 2019, Filtered-DiskANN WWW 2023, FreshDiskANN 2021, In-Place Updates 2025). Although the author list overlaps heavily with the DiskANN lineage, those cited results are real external evidence: they are open-source, benchmarked outside this paper's fitted values, and do not depend on the present paper's claims. The main weakness is external validity rather than circularity: Table 1 compares Cosmos DB's measured 70 RU at 94.64% recall@10 with competitor pricing units without demonstrating matched recall or index configurations, so the abstract's 43x/12x cost ratios are not established. That is a correctness concern about an unsupported comparison, not a reduction of a prediction to its own inputs, and it does not raise the circularity score.

Assumptions & free parameters 6 free parameters · 4 assumptions · 1 invented entities

The central claims rest on a small number of hand-chosen operating parameters (L, R, PQ sizes, beta, partition count), several unverified internal system properties (Bw-Tree latencies), and an uncontrolled pricing comparison. No new physical entities are proposed; the only invented software abstraction is the Forward Term value type, whose evidence is internal to this paper.

free parameters (6)
  • search list size L (searchListSizeMultiplier) = L=50 (headline latency, recall 91.43%), L=100 (cost comparison, recall 94.64%), L up to 200
    Determines the greedy search frontier size and directly controls recall, latency, and RU cost. Chosen per experiment, not fitted; the abstract's <20ms claim and the cost table depend on these hand-picked operating points.
  • graph degree bound R = 32
    Out-degree bound for DiskANN graph; set to minimize index footprint and match replica memory constraints. The cost and latency numbers depend on this choice.
  • PQ quantization sizes = Wiki-Cohere 192 bytes, MSTuring 50 bytes, OpenAI text-3-large 128 bytes navigation / 256 bytes pruning
    Quantization compression rate determines index memory footprint and recall. The text states that navigation works at 128 bytes but pruning needs 256 bytes; these were chosen empirically for each dataset.
  • quantizedVectorListMultiplier = 7 (example query); not specified in experiments
    Controls number of candidates fetched before reranking in quantized space; directly affects recall and RU cost. Not swept systematically in the paper.
  • filter-aware beta = 0.3
    Distance-scale factor in Algorithm 7 for filter-aware search; chosen for YFCC filtered-query experiments. Changing beta changes recall and latency tradeoff.
  • partition count for 10M Wiki-Cohere index = 2
    The 'less than 2x cost increase over 100x index size' result uses 2 partitions for 10M while 100K/1M use 1, confounding the scale-up comparison; the authors state it could have fit in one partition.
assumptions (4)
  • domain assumption DiskANN graph search has empirically logarithmic query complexity in index size.
    Used in Section 1 and 3 to argue that a single large per-partition index scales efficiently. Based on prior measurements by the same group, not established in this paper.
  • domain assumption Bw-Tree provides the assumed read latencies and supports blind incremental updates for adjacency lists at scale.
    The design and the ingestion cost estimate in Section 4.4 use 10us per quantized vector read and 25us per adjacency list read; these are internal Cosmos DB properties the paper states but does not independently verify.
  • domain assumption Competitor pricing pages as of July 14, 2025 reflect comparable serverless enterprise offerings at comparable recall.
    Table 1 and the 43x/12x cost claims assume the converted RU/query numbers for Pinecone, Zilliz, and DataStax are directly comparable to Cosmos DB's measured RU charges at 94.64% recall, with no evidence of competitor recall levels or index configurations.
  • domain assumption Product quantization at the stated compression ratios preserves enough distance information for graph traversal and pruning.
    Section 3.2 asserts quantized-space search and pruning work without losing index quality, citing earlier DiskANN observations. This is an empirical property of PQ, not proven here.
invented entities (1)
  • Forward Term value type in Cosmos DB Bw-Tree
    purpose: Stores arbitrary values (adjacency lists) as TermValues instead of the bitmap used by inverted terms, enabling fast appends for DiskANN graph edges
    Introduced in Section 3.3 as a new index term design. Its performance is validated only through the experiments in this paper; no independent external evidence exists.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Cost-Effective, Low Latency Vector Search with Azure Cosmos DB." pith.science (2026). https://pith.science/paper/VSY4EZHR

@misc{pith2026250505885,
  author       = {Pith},
  title        = {Pith review of: Cost-Effective, Low Latency Vector Search with Azure Cosmos DB},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/VSY4EZHR}},
  note         = {Machine review of arXiv:2505.05885}
}
read the original abstract

Vector indexing enables semantic search over diverse corpora and has become an important interface to databases for both users and AI agents. Efficient vector search requires deep optimizations in database systems. This has motivated a new class of specialized vector databases that optimize for vector search quality and cost. Instead, we argue that a scalable, high-performance, and cost-efficient vector search system can be built inside a cloud-native operational database like Azure Cosmos DB while leveraging the benefits of a distributed database such as high availability, durability, and scale. We do this by deeply integrating DiskANN, a state-of-the-art vector indexing library, inside Azure Cosmos DB NoSQL. This system uses a single vector index per partition stored in existing index trees, and kept in sync with underlying data. It supports < 20ms query latency over an index spanning 10 million vectors, has stable recall over updates, and offers approximately 43x and 12x lower query cost compared to Pinecone and Zilliz serverless enterprise products. It also scales out to billions of vectors via automatic partitioning. This convergent design presents a point in favor of integrating vector indices into operational databases in the context of recent debates on specialized vector databases, and offers a template for vector indexing in other databases.

Figures

Figures reproduced from arXiv: 2505.05885 by the authors.

Figure 1
Figure 1. Azure CosmosDB architecture diagram from [32]. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. A comparison of the storage media for monolithic [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Control flow of paginated search. the term in the correct replica. The context can also contain LSN and activity_id to help the database emit telemetry for debugging and fine-grained performance metrics. Our rewrite achieved these goals without compromising on performance compared to monolithic “in-memory” libraries such as [14, 35]. We can implement the Provider traits using a type backed by memory buffers for maxi… view at source ↗
Figures from the paper (12 more)
Figure 4
Figure 4. Figure 4: Index term design for quantized vectors (top) and [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: Re-ranking 10 closest neighbors retrieved in quan￾tized space using full-precision vectors to find the top 𝑘 = 4. quantizedVectorListMultiplier=2.5. If a DiskANN index is present, then the query engine calls the Paginated search API to get the number of documents requi…
Figure 7
Figure 7. Figure 7: p50, p95 and p99 query latencies and query RU [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 6
Figure 6. Figure 6: p50, p95 and p99 query latencies and query RU 20 Lat 1M 100K [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 9
Figure 9. Figure 9: Comparison of the query latency and cost of post [PITH_FULL_IMAGE:figures/full_fig_p009_9.png]
Figure 10
Figure 10. Figure 10: Query latency and RU charge for 1 billion (Left) [PITH_FULL_IMAGE:figures/full_fig_p009_10.png]
Figure 11
Figure 11. Figure 11: Latency breakdown for single threaded MS Turing [PITH_FULL_IMAGE:figures/full_fig_p010_11.png]
Figure 12
Figure 12. Figure 12: shows ingestion progress with Resource Governance disabled to make it easier to analyze data. In practice, Resource Governance controls compute available to a single replica to ensure fairness. Earlier in the ingestion, the index cost to access quantized vector terms …
Figure 13
Figure 13. Figure 13: Recall trends for the runbooks described in Section 4. All runs used index parameters [PITH_FULL_IMAGE:figures/full_fig_p012_13.png]
Figure 14
Figure 14. Figure 14: Comparison of number of distance comparions [PITH_FULL_IMAGE:figures/full_fig_p016_14.png]
Figure 15
Figure 15. Figure 15: Control flow of a DiskANN query in Cosmos DB. [PITH_FULL_IMAGE:figures/full_fig_p017_15.png]
Figure 16
Figure 16. Figure 16: p50, p95 and p99 query latencies and query RU 0 [PITH_FULL_IMAGE:figures/full_fig_p018_16.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

50 extracted references · 31 canonical work pages

  1. [1]

    Tokio Runtime

    2016. Tokio Runtime. https://tokio.rs/

    work page 2016

  2. [2]

    Raykar, Kirankumar Shiragur, and Haike Xu

    Piyush Anand, Piotr Indyk, Ravishankar Krishnaswamy, Sepideh Mahabadi, Vikas C. Raykar, Kirankumar Shiragur, and Haike Xu. 2025. Graph-Based Algo- rithms for Diverse Similarity Search. CoRR 2502.13336 (2025). arXiv:2502.13336 http://arxiv.org/abs/2502.13336

    arXiv 2025

  3. [3]

    Razenshteyn, and Ludwig Schmidt

    Alexandr Andoni, Piotr Indyk, Thijs Laarhoven, Ilya P. Razenshteyn, and Ludwig Schmidt. 2015. Practical and Optimal LSH for Angular Distance. In Advances in Neural Information Processing Systems 28: Annual Conference on Neural Infor- mation Processing Systems 2015, December 7-12, 2015, Montreal, Quebec, Canada , Corinna Cortes, Neil D. Lawrence, Daniel D....

    work page 2015

  4. [4]

    Andrew Kane et al. 2024. https://github.com/pgvector/pgvector

    work page 2024

  5. [5]

    Ilias Azizi, Karima Echihabi, and Themis Palpana. 2023. Elpis: Graph-Based Similarity Search for Scalable Data Science. Proceedings of the VLDB Endowment (PVLDB) Journal 16 (2023). Issue 6

    work page 2023

  6. [6]

    Cheng Chen, Chenzhe Jin, Yunan Zhang, Sasha Podolsky, Chun Wu, Szu- Po Wang, Eric Hanson, Zhou Sun, Robert Walzer, and Jianguo Wang. 2024. SingleStore-V: An Integrated Vector Database System in SingleStore. Proc. VLDB Endow. 17, 12 (Aug. 2024), 3772–3785. https://doi.org/10.14778/3685800.3685805

    arXiv 2024

  7. [7]

    Qi Chen, Bing Zhao, Haidong Wang, Mingqin Li, Chuanjie Liu, Zengzhong Li, Mao Yang, and Jingdong Wang. 2021. SPANN: Highly-efficient Billion- scale Approximate Nearest Neighborhood Search. In Advances in Neural Information Processing Systems , M. Ranzato, A. Beygelzimer, Y. Dauphin, P.S. Liang, and J. Wortman Vaughan (Eds.), Vol. 34. Curran Associates, In...

    work page 2021

  8. [8]

    Microsoft Corporation. 2024. Hierarchical partition keys in Azure Cosmos DB. https://learn.microsoft.com/en-us/azure/cosmos-db/hierarchical-partition- keys?tabs=net-v3%2Cbicep

    work page 2024

Show all 50 references
  1. [9]

    Microsoft Corporation. 2024. Indexing policies in Azure Cosmos DB. https: //learn.microsoft.com/en-us/azure/cosmos-db/index-policy

    2024

  2. [10]

    DataStax. 2025. DataStax Vector Search Pricing. https://www.datastax.com/ pricing/vector-search

    2025

  3. [11]

    Cosmos DB. 2024. Vector Index Scenario Suite. https://github.com/ AzureCosmosDB/VectorIndexScenarioSuite

    2024

  4. [12]

    Matthijs Douze, Alexandr Guzhva, Chengqi Deng, Jeff Johnson, Gergely Szilvasy, Pierre-Emmanuel Mazaré, Maria Lomeli, Lucas Hosseini, and Hervé Jégou. 2024. The Faiss library. CoRR abs/2401.08281 (2024). https://doi.org/10.48550/ARXIV. 2401.08281 arXiv:2401.08281

    2024 doi arXiv

  5. [13]

    Simon Hørup Eskildsen. 2024. turbopuffer: fast search on object storage. https: //turbopuffer.com/blog/turbopuffer

    2024

  6. [14]

    Yury Malkov et al. 2019. Header-only C++/python library for fast approximate nearest neighbors. https://github.com/nmslib/hnswlib

    2019

  7. [15]

    Cong Fu, Chao Xiang, Changxu Wang, and Deng Cai. 2019. Fast Approximate Nearest Neighbor Search With The Navigating Spreading-out Graphs. PVLDB 12, 5 (2019), 461 – 474. https://doi.org/10.14778/3303753.3303754

    2019

  8. [16]

    Siddharth Gollapudi, Neel Karia, Varun Sivashankar, Ravishankar Krishnaswamy, Nikit Begwani, Swapnil Raz, Yiyong Lin, Yin Zhang, Neelam Mahapatro, Premku- mar Srinivasan, Amit Singh, and Harsha Vardhan Simhadri. 2023. Filtered- DiskANN: Graph Algorithms for Approximate Nearest...

    2023

  9. [17]

    Ruiqi Guo, Philip Sun, Erik Lindgren, Quan Geng, David Simcha, Felix Chern, and Sanjiv Kumar. 2020. Accelerating Large-Scale Inference with Anisotropic Vector Quantization. In Proceedings of the 37th International Conference on Machine Learning, ICML 2020, 13-18 July 2020, Vir...

    2020

  10. [18]

    HNSW. 2023. HNSW Github. https://github.com/nmslib/hnswlib/blob/master/ examples/python/EXAMPLES.md

    2023

  11. [19]

    Herve Jegou, Matthijs Douze, and Cordelia Schmid. 2010. Product Quantization for Nearest Neighbor Search. IEEE Transactions on Pattern Analysis and Machine Intelligence (TPAMI) 33, 1 (2010)

    2010

  12. [20]

    Jeff Johnson, Matthijs Douze, and Hervé Jégou. 2017. Billion-scale Similarity Search with GPUs. arXiv preprint arXiv:1702.08734 (2017)

    2017 arXiv

  13. [21]

    Jonathan Ellis et al. 2024. JVector. https://github.com/jbellis/jvector

    2024

  14. [22]

    Ravishankar Krishnaswamy, Magdalen Manohar, and Harsha Vardhan Simhadri

  15. [23]

    Malkov and D

    Yury A. Malkov and D. A. Yashunin. 2016. Efficient and Robust Approximate Nearest Neighbor Search using Hierarchical Navigable Small World graphs.CoRR abs/1603.09320 (2016). arXiv:1603.09320 http://arxiv.org/abs/1603.09320

    2016 arXiv

  16. [24]

    Magdalen Manohar, James Codella, Mark Hildebrand, Harsha Vardhan Simhadri, and Ravishankar Krishnaswamy. 2024. Microsoft DiskANN in Azure Cosmos DB. https://github.com/AzureCosmosDB/DiskANNWhitePapers/blob/ fc97578ee687189af3a086b35218f368f36b3085/Microsoft%20DiskANN%20in% 20A...

    2024

  17. [25]

    Blelloch, Laxman Dhulipala, Yan Gu, Harsha Vardhan Simhadri, and Yihan Sun

    Magdalen Dobson Manohar, Zheqi Shen, Guy E. Blelloch, Laxman Dhulipala, Yan Gu, Harsha Vardhan Simhadri, and Yihan Sun. 2024. ParlayANN: Scalable and Deterministic Parallel Graph-Based Approximate Nearest Neighbor Search Algorithms. In Proceedings of the 29th ACM SIGPLAN Annua...

    2024

  18. [26]

    Matvey Arye et al. 2025. pgvectorscale. https://github.com/timescale/ pgvectorscale

    2025

  19. [27]

    Microsoft. 2025. Azure Compliance Offerings. https://servicetrust.microsoft. com/DocumentPage/7adf2d9e-d7b5-4e71-bad8-713e6a183cf3

    2025

  20. [28]

    Pavan Davuluri. 2024. Windows Copilot Runtime. https://blogs.windows. com/windowsdeveloper/2024/05/21/unlock-a-new-era-of-innovation-with- windows-copilot-runtime-and-copilot-pcs/

    2024

  21. [29]

    Nick Pentreath, Abdulla Abdurakhmanov, and Rob Royce. 2017. Vector Scor- ing Plugin for Elasticsearch. https://github.com/MLnick/elasticsearch-vector- scoring

    2017

  22. [30]

    Pinecone. 2025. PineCone Serverless Pricing Documents. https://docs.pinecone. io/guides/organizations/manage-cost/understanding-cost#query

    2025

  23. [31]

    Nils Reimers. 2022. Datasets: Cohere/wikipedia-22-12-en-embeddings. https: //huggingface.co/datasets/Cohere/wikipedia-22-12-en-embeddings

    2022

  24. [32]

    Dharma Shukla, Shireesh Thota, Karthik Raman, Madhan Gajendran, Ankur Shah, Sergii Ziuzin, Krishnan Sundaram, Miguel Gonzalez Guajardo, Anna Wawrzy- niak, Samer Boshra, Renato Ferreira, Mohamed Nassar, Michael Koltachev, Ji Huang, Sudipta Sengupta, Justin Levandoski, and David...

    2015

  25. [34]

    Harsha Vardhan Simhadri, Martin Aumüller, Amir Ingber, Matthijs Douze, George Williams, Magdalen Dobson Manohar, Dmitry Baranchuk, Edo Liberty, Frank Liu, Ben Landrum, Mazin Karjikar, Laxman Dhulipala, Meng Chen, Yue Chen, Rui Ma, Kai Zhang, Yuzheng Cai, Jiayang Shi, Yizhuo Ch...

    2024 arXiv

  26. [35]

    Harsha Vardhan Simhadri, Ravishankar Krishnaswamy, Gopal Srinivasa, Suhas Jayaram Subramanya, Andrija Antonijevic, Dax Pryce, David Kaczynski, Shane Williams, Siddarth Gollapudi, Varun Sivashankar, Neel Karia, Aditi Singh, Shikhar Jaiswal, Neelam Mahapatro, Philip Adams, Bryan...

  27. [36]

    Aditi Singh, Suhas Jayaram Subramanya, Ravishankar Krishnaswamy, and Har- sha Vardhan Simhadri. 2021. FreshDiskANN: A Fast and Accurate Graph- Based ANN Index for Streaming Similarity Search. CoRR abs/2105.09613 (2021). arXiv:2105.09613 https://arxiv.org/abs/2105.09613

    2021 arXiv

  28. [37]

    Rodrigo Souza. 2024. CosmosDB Dev Blog. https://devblogs.microsoft.com/ cosmosdb/announcing-cost-and-performance-improvements-with-azure- cosmos-dbs-binary-encoding/

    2024

  29. [38]

    Suhas Jayaram Subramanya, Devvrit, Rohan Kadekodi, Ravishankar Krish- naswamy, and Harsha Vardhan Simhadri. 2019. DiskANN: Fast Accurate Billion- point Nearest Neighbor Search on a Single Node. In Advances in Neural Informa- tion Processing Systems 32: Annual Conference on Neu...

    2019

  30. [39]

    Julie Tibshirani. 2019. Text similarity search with vector fields. https://www. elastic.co/blog/text-similarity-search-with-vectors-in-elasticsearch

    2019

  31. [40]

    Benjamin Trent. 2023. Make HNSW merges faster. https://github.com/apache/ lucene/issues/12440

    2023

  32. [41]

    Benjamin Trent. 2024. Make HNSW merges cheaper on heap. https://github. com/apache/lucene/issues/14208

    2024

  33. [42]

    Turbopuffer. 2025. TurboPuffer Pricing. https://turbopuffer.com/pricing

    2025

  34. [43]

    Chuangxian Wei, Bin Wu, Sheng Wang, Renjie Lou, Chaoqun Zhan, Feifei Li, and Yuanzhe Cai. 2020. AnalyticDB-V: A Hybrid Analytical Engine Towards Query Fusion for Structured and Unstructured Data. Proc. VLDB Endow. 13, 12 (2020), 3152–3165. https://doi.org/10.14778/3415478.3415541

    2020

  35. [44]

    Bernstein, Badrish Chan- dramouli, Richard Wen, and Harsha Vardhan Simhadri

    Haike Xu, Magdalen Dobson Manohar, Philip A. Bernstein, Badrish Chan- dramouli, Richard Wen, and Harsha Vardhan Simhadri. 2025. In-Place Updates of a Graph Index for Streaming Approximate Nearest Neighbor Search. CoRR abs/2502.13826 (2025). https://doi.org/10.48550/ARXIV.2502....

    2025 doi arXiv

  36. [45]

    Yuming Xu, Hengyu Liang, Jin Li, Shuotao Xu, Qi Chen, Qianxi Zhang, Cheng Li, Ziyue Yang, Fan Yang, Yuqing Yang, Peng Cheng, and Mao Yang. 2023. SPFresh: Incremental In-Place Update for Billion-Scale Vector Search. In Pro- ceedings of the 29th Symposium on Operating Systems Pr...

    2023

  37. [46]

    Bennett, Nick Craswell, and Saurabh Tiwary

    Hongfei Zhang, Xia Song, Chenyan Xiong, Corby Rosset, Paul N. Bennett, Nick Craswell, and Saurabh Tiwary. 2019. Generic Intent Representation in Web Search. In Proceedings of the 42nd International ACM SIGIR Conference on Research and Development in Information Retrieval, SIGI...

    2019 doi

  38. [47]

    Qianxi Zhang, Shuotao Xu, Qi Chen, Guoxin Sui, Jiadong Xie, Zhizhen Cai, Yaoqi Chen, Yinxuan He, Yuqing Yang, Fan Yang, Mao Yang, and Lidong Zhou

  39. [48]

    waker" that moves a task from an “idle

    Zilliz. 2025. Zilliz Serverless Pricing Documents. https://docs.zilliz.com/docs/ understand-cost#example Algorithm 4: Index Construction Data: Dataset𝑃, degree bound𝑅, list size parameter𝐿, RNG parameter𝛼 Result: Navigable Graph𝐺 =(𝑃,𝐸), start node𝑠 let𝑠← arg min𝑝∈𝑃|| x𝑝− ∑︁ 𝑝...

    2025

  40. [50]

    In 17th USENIX Symposium on Operating Systems Design and Implementation (OSDI 23)

    VBASE: Unifying Online Vector Similarity Search and Relational Queries via Relaxed Monotonicity. In 17th USENIX Symposium on Operating Systems Design and Implementation (OSDI 23). USENIX Association, Boston, MA, 377–395. https://www.usenix.org/conference/osdi23/presentation/zh...

  41. [2023]

    https://github.com/Microsoft/DiskANN

    DiskANN: Graph-structured Indices for Scalable, Fast, Fresh and Filtered Approximate Nearest Neighbor Search. https://github.com/Microsoft/DiskANN

  42. [2025]

    IEEE Data Engineering Bulletin 48 (2025)

    The DiskANN library: Graph-Based Indices for Fast, Fresh and Filtered Vector Search. IEEE Data Engineering Bulletin 48 (2025). Issue 3

    2025

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.