Pith. sign in

REVIEW 3 major objections 5 minor 50 references

Bang for the Buck: Vector Search on Cloud CPUs

T0 review · 3 major / 5 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 Cloud CPU choice can triple queries per dollar for vector search, with Graviton3 usually best value.

desk verdict Useful cloud CPU benchmark, but the headline "Graviton3 best for most" is partly an artifact of the paper's scoring rule. read the letter →

arxiv 2505.07621 v1 pith:Z7FCGLNE submitted 2025-05-12 cs.DB cs.AI

Leonardo Kuffo , Peter Boncz This is my paper · ORCID
classification cs.DBcs.AI
keywords vectorsearchqueriesperdollarcloudCPUbenchmarkingGraviton3SIMDkernelsquantizationHNSWIVF
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

This paper shows that the best cloud CPU for vector search depends on the index type, quantization level, and instance price, not just on raw SIMD power. The authors benchmarked IVF, HNSW, and full scans at several quantization levels on six AWS instances spanning Intel, AMD, and ARM designs, measuring both queries per second (QPS) and queries per dollar (QP$). Their central result is that no CPU wins everywhere: AMD Zen4 gives almost 3x the QPS of Intel Sapphire Rapids on IVF with float32 vectors, Intel Sapphire Rapids leads HNSW throughput, and the cheaper ARM instances, especially Graviton3, often deliver the best QP$. If the ranking holds, users can get roughly 3x more queries per dollar simply by matching the CPU to the search workload, which matters for any pay-per-query cloud deployment.

What carries the argument

The central measurement object is QP$, queries per second divided by the instance's hourly on-demand price, which the paper uses to rank value rather than raw speed. The explanatory machinery is a two-factor account of why rankings flip: (1) the search algorithm's data-access pattern, sequential bulk reads for IVF and full scans versus cache-resident walks over HNSW graphs, combined with each microarchitecture's load bandwidth, sequential latency at L3/DRAM, and SIMD register width; and (2) whether the distance kernel computes symmetrically in the quantized domain, as in USearch, or first decodes to float32, as in FAISS, which on ARM makes scalar-quantized vectors several times slower. Together these factors explain the headline results: Zen4 dominates bandwidth-hungry scans, Sapphire Rapids wins HNSW throughput, and Graviton3 wins on cost.

What would settle it

Replace FAISS's ARM scalar path for scalar-quantized vectors with a SIMD-optimized kernel, or benchmark a third library with symmetric 8-bit kernels on ARM, and rerun the IVF and full-scan measurements; if Graviton3 no longer leads in QP$ across most settings, the central ranking is an artifact of a missing kernel rather than of the hardware.

Watch

Extended reading notes

Core claim

The paper's central claim is that the queries-per-dollar ranking of cloud CPUs is scenario-dependent, and that on current AWS pricing Graviton3 (r7g) is the best value option for most vector search settings, even beating its successor Graviton4, while AMD Zen4 (r7a) is the strongest raw performer for IVF indexes and full scans on float32 vectors. The differences are not random: they follow from the interaction between two mechanisms. Sequential, bandwidth-hungry access patterns in IVF and full scans favor CPUs with high L3/DRAM read bandwidth and low sequential latency, where Gravitons and Zens excel and Sapphire Rapids falls behind, while cache-friendlier graph traversal in HNSW favors Sapphire Rapids' high L1 load bandwidth and wider SIMD. Kernel implementation also matters: the FAISS library decodes scalar-quantized vectors back to float32 with scalar code on ARM, which depresses Graviton QPS in scalar-quantized scenarios by up to 3-6x, whereas the USearch library's symmetric quantized kernels let the same instances lead on 8-bit full scans.

Load-bearing premise

The rankings depend on the two benchmarked libraries representing each CPU's achievable performance; in particular, FAISS's scalar ARM code for scalar-quantized vectors may understate what Graviton instances could deliver, so a better-optimized library could change which CPU looks cheapest.

Editorial extensions

If this is right

  • Deploying HNSW in production should not default to the newest CPU: Intel Sapphire Rapids Z gives the highest QPS, but Zen3 and Graviton3 return more queries per dollar on high-dimensional data.
  • For IVF indexes and full scans on float32 or bfloat vectors, choosing AMD Zen4 over Intel Sapphire Rapids can yield roughly 3x more QPS and QP$.
  • Quantization level changes the ranking: at 8-bit scalar quantization Intel and AMD widen their lead, while at 1-bit and float16 the ARM instances become the cost leaders.
  • Users can realize about 3x more queries per dollar by matching microarchitecture to workload, an effect comparable to switching algorithms or libraries.
  • Newer cloud CPU generations are not automatically better for vector search: Graviton3 beats Graviton4 in many settings because its 256-bit SVE registers outperform Graviton4's 128-bit SVE registers.
  • A third library with symmetric 8-bit kernels on ARM would test whether Graviton3 remains the cost leader in scalar-quantized settings.

Reading between the lines

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

  • If a vector library adds NEON/SVE kernels that decode 8-bit quantized vectors symmetrically on ARM, the Gravitons' scalar-quantization disadvantage would likely shrink, extending their QP$ advantage to more scenarios than the paper reports.
  • The single-threaded, no-update protocol may understate how batch queries or index construction affect rankings, since memory bandwidth saturation and load-port behavior differ under multi-query execution.
  • The durable insight is mechanistic rather than tied to today's instances: procurement for serverless vector services should be guided by data-access pattern and kernel efficiency, not by CPU generation or list price alone.
  • Because QP$ divides by hourly price, the absolute winning instance could shift with AWS pricing; the paper's specific instance ranking is time-sensitive, while the underlying bandwidth-versus-SIMD explanation is not.
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

3 major / 5 minor

Summary. This paper presents an experimental benchmark of vector similarity search on six AWS cloud CPU microarchitectures (Graviton3, Graviton4, Zen3, Zen4, Sapphire Rapids, and Sapphire Rapids Z), using FAISS and USearch across HNSW, IVF, and full-scan workloads with multiple quantization levels and three datasets of different dimensionality. The main empirical findings are that relative CPU performance depends strongly on the index type and quantization setting, with Zen4 leading IVF/full scans in QPS, Intel Sapphire Rapids leading HNSW in QPS, and Graviton3 often being the best in queries per dollar (QP$) once instance price is considered. The paper aggregates the per-setting QPS and QP$ results into a categorical scoring table and uses this table to support the headline claim that Graviton3 gives the best 'bang for the buck' for most indexes and quantization settings, even over Graviton4.

Significance. The work addresses a timely and practically important question, and the raw measurements are valuable: the authors vary index type, quantization, dataset dimensionality, and CPU, and they supplement the query benchmarks with memory bandwidth and latency measurements that explain the observed differences. If the results hold, they provide clear, actionable guidance for cloud users, potentially yielding several-fold improvements in QPS or QP$ by matching CPU choice to the workload. The paper also deserves credit for explicitly acknowledging the main software-level limitation, namely the absence of optimized ARM SIMD kernels in FAISS for scalar quantization, and for using open, well-known datasets and libraries. However, the headline claim rests on a categorical scoring system whose robustness is not examined, and the experimental protocol omits variance information and exact recall operating points; these issues need to be addressed before the quantitative ranking can be considered established.

major comments (3)
  1. [Section 4 and Table 1] The central claim that Graviton3 gives the best QP$ 'for most indexes and quantization settings' is not read directly from the measured QP$ values but from the categorical scoring system in Table 1. That system applies arbitrary thresholds (20%, 2x, 3x) and assigns +1/-1 per symbol, making it insensitive to the magnitude of differences and weighting every configuration equally. For example, in the OpenAI/1536 FAISS full-scan SQ6 column of Table 6, SPR's QP$ is about 4.4x Graviton3's (3.1 vs. 0.7), yet this counts as only a single category difference, while a long run of middle-ground '·' cells contributes zero. No sensitivity analysis is provided, so the abstract's 'best for most' claim is a property of this particular aggregation rule rather than a demonstrated robust property of the data. I ask the authors to show how the ranking changes under alternative aggregations, such as geometric-mean QP$ across settings, counting only settings where a CPU is within a fixed fraction of the best, or using the raw QP$ ratios directly.
  2. [Section 3.1 and Tables 4-6] All cross-CPU QPS/QP$ comparisons in Tables 4-6 are reported 'at the highest possible recall', but the paper never states the recall values, whether they are equal across microarchitectures, or how they were determined. If one CPU reaches a higher recall than another at its respective 'highest' setting, the QPS comparison mixes accuracy and speed and is not an apples-to-apples comparison. Since the central comparisons are cross-machine, the authors should fix a target recall or, alternatively, report the achievable recall per machine and show recall-vs-QPS curves for at least the settings that determine the headline ranking.
  3. [Section 3 (experimental methodology)] The paper does not report the number of repetitions per measurement, standard deviations, or run-to-run variability, and it states only that queries were run individually with k=10. For benchmark claims that drive a specific recommendation, the lack of error bars is a concern, especially because some Table 1 score totals are separated by only one point. Please add a methodology paragraph covering warmup, the number of queries per run, how many times each experiment was repeated, and how the 'highest possible recall' operating point was found, and report variance for the results that determine the ranking.
minor comments (5)
  1. [Section 3 and Table captions] The QP$ metric is used throughout but never explicitly defined. Please state the formula, e.g., QP$ = QPS × 3600 / (price per hour), and clarify the normalization used in each table, since Table 4 and Table 5 values are in units of 10^5 while Table 6 values appear to be in units of 10^4, with some entries such as the BQ full-scan values exceeding that order.
  2. [Section 4 and Table 1] The scoring description says 'each (+) is 1 and each (-) is -1' but does not explain how the '++' and '--' symbols are counted. Please state explicitly whether '++' contributes two points and '--' contributes minus two, or whether the symbols are intended only as labels for the best and worst tiers.
  3. [Section 3] The claim that FAISS uses scalar code to decode quantized vectors on ARM CPUs is important for explaining the Graviton results, but no evidence or source reference is provided. Please cite the relevant FAISS implementation or verify the claim with a small microbenchmark, so readers can assess how specific this limitation is to the tested version.
  4. [Section 3.4] When comparing Graviton3 and Graviton4, the paper states that most benchmarks show Graviton4 delivering more performance but does not cite examples. Adding one or two references here would help readers weigh the claimed novelty of this observation.
  5. [Section 4] The sentence 'Graviton3 is only pushed back in our scoring system due to the lack of symmetric kernels in FAISS' is easy to misread; it means that Graviton3's score would be even higher if FAISS had ARM-optimized kernels. Please rephrase to make the direction of the effect explicit.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: all QPS/QP$ results are externally measured benchmarks; the Table 1 tier scoring is a post-hoc summary of those measurements, not an input that generates them.

full rationale

This is an experimental benchmarking paper. Every performance claim is grounded in measured QPS and QP$ values that are reported in Tables 4, 5, and 6 for FAISS and USearch across three datasets, five cloud microarchitectures, multiple index types, and multiple quantization levels. There is no fitted parameter that is later renamed as a prediction, no model derived from the data that is then used to explain the same data, and no uniqueness theorem imported from the authors' prior work. The central claim that Graviton3 offers the best 'bang for the buck' is a direct reading of measured QP$ values, as shown by the fact that Graviton3 leads or ties the QP$ column in a large number of cells in the OpenAI/1536 tables. The Table 1 tier system (++, +, ., -, --) and the associated +1/-1 score are an aggregation of these measured values; the aggregation is a summarization device, not a generative input. The choice of thresholds (20%, 2x, 3x) and equal weighting of configurations is debatable as a methodology for ranking, but that is a robustness or presentation concern, not circularity, because the underlying measurements stand independently of the scoring rule. The paper explicitly acknowledges the main contingency: 'Graviton3 is only pushed back in our scoring system due to the lack of symmetric kernels in FAISS' (Section 4), which further confirms that the conclusions are stated as contingent on library kernel implementations rather than being derived from the claim itself. The only author self-citation of note ([21], PDX) is used to support the general point that vector search is data-access bound, which is also supported by external references [31,34,41]; it is not load-bearing for the benchmark conclusions. No circular step can be exhibited from the paper's text, so the appropriate finding is no significant circularity (score 0).

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

The central claims rest on the representativeness of the two libraries, the chosen cloud price basis, the selected workloads, and the hand-built scoring thresholds. No mathematical axioms or new entities are introduced.

free parameters (2)
  • Table 1 scoring thresholds = 20%, 2x, 3x; +1 for '+', -1 for '-'
    The summary claim that Graviton3 has the best QP$ and Zen4 the best QPS uses these hand-chosen tier boundaries and point values. No sensitivity analysis is provided.
  • Recall operating point = Highest possible recall per configuration
    Tables 4 to 6 compare microarchitectures at each setting's highest achievable recall, which may correspond to different nprobe or ef_search values and thus different amounts of work per query across CPUs.
assumptions (4)
  • domain assumption FAISS and USearch kernels represent typical vector search performance on each cloud CPU
    The study's QPS and QP$ rankings are measured only through these two libraries. The paper notes FAISS lacks SIMD-optimized decoding for SQ on ARM, so the Graviton3 QP$ lead is partly a software artifact (Section 3.1, Table 4).
  • domain assumption AWS on-demand list prices in us-east-1 at the time of the study are the correct cost basis for QP$
    QP$ is defined as QPS divided by the hourly list price. Reserved or discount pricing, regional differences, or price changes would alter the QP$ rankings.
  • domain assumption The three datasets and single-threaded k=10 queries are representative of vector search workloads
    The paper benchmarks only L2 and Hamming distances, no batch queries, no updates, and no index construction. The authors themselves encourage data-driven benchmarks for other settings (Section 5).
  • ad hoc to paper The Table 1 tier scoring system is a meaningful aggregation of QPS and QP$
    The abstract's 'Graviton3 best' summary relies on the ad hoc +1 and -1 scoring in Table 1; different thresholds or weighting could change the ranking.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Bang for the Buck: Vector Search on Cloud CPUs." pith.science (2026). https://pith.science/paper/Z7FCGLNE

@misc{pith2026250507621,
  author       = {Pith},
  title        = {Pith review of: Bang for the Buck: Vector Search on Cloud CPUs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/Z7FCGLNE}},
  note         = {Machine review of arXiv:2505.07621}
}
abstract

Vector databases have emerged as a new type of systems that support efficient querying of high-dimensional vectors. Many of these offer their database as a service in the cloud. However, the variety of available CPUs and the lack of vector search benchmarks across CPUs make it difficult for users to choose one. In this study, we show that CPU microarchitectures available in the cloud perform significantly differently across vector search scenarios. For instance, in an IVF index on float32 vectors, AMD's Zen4 gives almost 3x more queries per second (QPS) compared to Intel's Sapphire Rapids, but for HNSW indexes, the tables turn. However, when looking at the number of queries per dollar (QP$), Graviton3 is the best option for most indexes and quantization settings, even over Graviton4 (Table 1). With this work, we hope to guide users in getting the best "bang for the buck" when deploying vector search systems.

Figures

Figures reproduced from arXiv: 2505.07621 by the authors.

Figure 2
Figure 2. Overview of different quantization techniques. [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. QPS and QP$ of cloud instances running queries on a FAISS IVF index without quantization (float32). The Zen4 [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 4
Figure 4. QPS and QP$ of cloud instances running queries on a flat HNSW index (float32). Intel Z takes the upper hand in QPS, [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figures from the paper (1 more)
Figure 5
Figure 5. Figure 5: SIMD read bandwidth and access latency (random and sequential) of cache and DRAM in cloud CPUs. [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

50 extracted references · 23 canonical work pages

  1. [1]

    Andreas Abel and Jan Reineke. 2019. uops. info: Characterizing latency, through- put, and port usage of instructions on intel microarchitectures. In Proceedings of the Twenty-Fourth International Conference on Architectural Support for Program- ming Languages and Operating Systems . 673–686

    work page 2019

  2. [2]

    Azim Afroozeh and Peter Boncz. 2023. The FastLanes Compression Layout: Decoding > 100 Billion Integers per Second with Scalar Code. Proc. VLDB Endow. 16, 9 (jul 2023), 2132–2144. https://doi.org/10.14778/3598581.3598587

    arXiv 2023

  3. [3]

    Cecilia Aguerrebere, Ishwar Bhati, Mark Hildebrand, Mariano Tepper, and Ted Willke. 2023. Similarity search in the blink of an eye with compressed indices. arXiv preprint arXiv:2304.04759 (2023)

    arXiv 2023

  4. [4]

    Cecilia Aguerrebere, Mark Hildebrand, Ishwar Singh Bhati, Theodore Willke, and Mariano Tepper. 2024. Locally-Adaptive Quantization for Streaming Vector Search. arXiv preprint arXiv:2402.02044 (2024)

    arXiv 2024

  5. [5]

    Arm Limited. 2022. Arm Neoverse V1 Software Optimization Guide . Version 6.0

    work page 2022

  6. [6]

    Arm Limited. 2022. Arm Neoverse V2 Software Optimization Guide . Version 3.0

    work page 2022

  7. [7]

    Martin Aumüller, Erik Bernhardsson, and Alexander Faithfull. 2020. ANN- Benchmarks: A benchmarking tool for approximate nearest neighbor algorithms. Information Systems 87 (2020), 101374

    2020

  8. [8]

    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. Advances in Neural Information Processing Systems 34 (2021), 5199–5212

    2021

Show all 50 references
  1. [9]

    Chroma. 2024. Single-Node Chroma: Performance and Limitations. https://docs. trychroma.com/production/administration/performance

    2024

  2. [10]

    Kumar Shivendu David Myriel. 2024. Intel’s New CPU Powers Faster Vector Search. https://qdrant.tech/blog/qdrant-cpu-intel-benchmark/

    2024

  3. [11]

    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. arXiv preprint arXiv:2401.08281 (2024)

    2024 arXiv

  4. [12]

    Agner Fog. 2016. The microarchitecture of Intel, AMD and VIA CPUs: An optimization guide for assembly programmers and compiler makers. Software optimization resources (2016)

    2016

  5. [13]

    Jianyang Gao, Yutong Gou, Yuexuan Xu, Yongyi Yang, Cheng Long, and Raymond Chi-Wing Wong. 2024. Practical and Asymptotically Optimal Quantization of High-Dimensional Vectors in Euclidean Space for Approximate Nearest Neighbor Search. arXiv preprint arXiv:2409.09913 (2024)

    2024 arXiv

  6. [14]

    Jianyang Gao and Cheng Long. 2023. High-dimensional approximate nearest neighbor search: with reliable and efficient distance comparison operations. Proceedings of the ACM on Management of Data 1, 2 (2023), 1–27

    2023

  7. [15]

    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 International Conference on Machine Learning. PMLR, 3887–3896

    2020

  8. [16]

    Masajiro Iwasaki and Daisuke Miyazaki. 2018. Optimization of indexing based on k-nearest neighbor graph for proximity search in high-dimensional data. arXiv preprint arXiv:1810.07355 (2018)

    2018 arXiv

  9. [17]

    Omid Jafari, Preeti Maurya, Parth Nagarkar, Khandker Mushfiqul Islam, and Chidambaram Crushev. 2021. A survey on locality sensitive hashing algorithms DaMoN ’25, June 23, 2025, Berlin, Germany Leonardo Kuffo and Peter Boncz and their applications. arXiv preprint arXiv:2102.089...

    2021 arXiv

  10. [18]

    Herve Jegou, Matthijs Douze, and Cordelia Schmid. 2010. Product quantization for nearest neighbor search. IEEE transactions on pattern analysis and machine intelligence 33, 1 (2010), 117–128

    2010

  11. [19]

    Zhi Jing, Yongye Su, Yikun Han, Bo Yuan, Haiyun Xu, Chunjiang Liu, Kehai Chen, and Min Zhang. 2024. When large language models meet vector databases: A survey. arXiv preprint arXiv:2402.01763 (2024)

    2024 arXiv

  12. [20]

    Anthony Ko, Iman Keivanloo, Vihan Lakshman, and Eric Schkufza. 2021. Low- precision quantization for efficient nearest neighbor search. arXiv preprint arXiv:2110.08919 (2021)

    2021 arXiv

  13. [21]

    Leonardo Kuffo, Elena Krippner, and Peter Boncz. 2025. PDX: A Data Layout for Vector Similarity Search. Proc. ACM Manag. Data (2025)

    2025

  14. [22]

    Chester Lam. 2023. Sapphire Rapids: Golden Cove Hits Servers. https:// chipsandcheese.com/p/a-peek-at-sapphire-rapids

    2023

  15. [23]

    Chester Lam. 2024. Arm’s Neoverse V2, in AWS’s Graviton 4. https:// chipsandcheese.com/p/arms-neoverse-v2-in-awss-graviton-4

    2024

  16. [24]

    Daniel Lemire. 2018. AVX-512: when and how to use these new instruc- tions. https://lemire.me/blog/2018/09/07/avx-512-when-and-how-to-use-these- new-instructions/

    2018

  17. [25]

    Yu A Malkov and Dmitry A Yashunin. 2018. Efficient and robust approximate nearest neighbor search using hierarchical navigable small world graphs. IEEE transactions on pattern analysis and machine intelligence 42, 4 (2018), 824–836

    2018

  18. [26]

    zilliz Milvus. 2020. Milvus performance on AVX-512 vs. AVX2. https://milvus.io/ blog/2020-11-10-milvus-performance-AVX-512-vs-AVX2.md

    2020

  19. [27]

    Javier Vargas Munoz, Marcos A Gonçalves, Zanoni Dias, and Ricardo da S Torres

  20. [28]

    Joe Oakley and Hakan Ferhatosmanoglu. 2025. SQUASH: Serverless and Dis- tributed Quantization-based Attributed Vector Similarity Search. arXiv preprint arXiv:2502.01528 (2025)

    2025 arXiv

  21. [29]

    James Jie Pan, Jianguo Wang, and Guoliang Li. 2023. Survey of vector database management systems. arXiv preprint arXiv:2310.14021 (2023)

    2023 arXiv

  22. [30]

    James Jie Pan, Jianguo Wang, and Guoliang Li. 2024. Vector Database Manage- ment Techniques and Systems. In Companion of the 2024 International Conference on Management of Data . 597–604

    2024

  23. [31]

    Yannis Papakonstantinou, Alan Li, Ruiqi Guo, Sanjiv Kumar, and Phil Sun. 2024. ScaNN for AlloyDB . Technical Report. Google Cloud. https://services.google. com/fh/files/misc/scann_for_alloydb_whitepaper.pdf Whitepaper

    2024

  24. [32]

    Liana Patel, Peter Kraft, Carlos Guestrin, and Matei Zaharia. 2024. Acorn: Perfor- mant and predicate-agnostic search over vector embeddings and structured data. Proceedings of the ACM on Management of Data 2, 3 (2024), 1–27

    2024

  25. [33]

    Meta Research. 2024. Faiss: A library for efficient similarity search and clustering of dense vectors. https://github.com/facebookresearch/faiss

    2024

  26. [34]

    Viktor Sanca and Anastasia Ailamaki. 2024. Efficient Data Access Paths for Mixed Vector-Relational Search. In Proceedings of the 20th International Workshop on Data Management on New Hardware . 1–9

    2024

  27. [35]

    Spotify. 2017. ANNOY by Spotify. https://github.com/spotify/annoy

    2017

  28. [36]

    Yongye Su, Yinqi Sun, Minjia Zhang, and Jianguo Wang. 2024. Vexless: A Server- less Vector Data Management System Using Cloud Functions. Proceedings of the ACM on Management of Data 2, 3 (2024), 1–26

    2024

  29. [37]

    Philip Sun, David Simcha, Dave Dopson, Ruiqi Guo, and Sanjiv Kumar. 2023. SOAR: improved indexing for approximate nearest neighbor search. Advances in Neural Information Processing Systems 36 (2023), 3189–3204

    2023

  30. [38]

    Ash Vardanian. 2023. SimSimd: Up to 200x Faster Dot Products & Similarity Metrics. https://github.com/ashvardanian/SimSIMD

    2023

  31. [39]

    Ash Vardanian. 2023. USearch by Unum Cloud . https://doi.org/10.5281/zenodo. 7949416

    2023 doi

  32. [40]

    Jianguo Wang, Xiaomeng Yi, Rentong Guo, Hai Jin, Peng Xu, Shengjun Li, Xi- angyu Wang, Xiangzhou Guo, Chengming Li, Xiaohai Xu, et al. 2021. Milvus: A purpose-built vector data management system. In Proceedings of the 2021 International Conference on Management of Data . 2614–2627

    2021

  33. [41]

    Mengzhao Wang, Haotian Wu, Xiangyu Ke, Yunjun Gao, Yifan Zhu, and Wenchao Zhou. 2025. Accelerating Graph Indexing for ANNS on Modern CPUs. arXiv preprint arXiv:2502.18113 (2025)

    2025 arXiv

  34. [42]

    Mengzhao Wang, Xiaoliang Xu, Qiang Yue, and Yuxiang Wang. 2021. A com- prehensive survey and experimental comparison of graph-based approximate nearest neighbor search. arXiv preprint arXiv:2101.12631 (2021)

    2021 arXiv

  35. [43]

    Duncan J Watts and Steven H Strogatz. 1998. Collective dynamics of ‘small- world’networks. nature 393, 6684 (1998), 440–442

    1998

  36. [44]

    Weaviate. 2019. Weaviate. https://github.com/weaviate/weaviate

    2019

  37. [45]

    Jiuqi Wei, Xiaodong Lee, Zhenyu Liao, Themis Palpanas, and Botao Peng. 2025. Subspace Collision: An Efficient and Accurate Framework for High-dimensional Approximate Nearest Neighbor Search. Proceedings of the ACM on Management of Data 3, 1 (2025), 1–29

    2025

  38. [46]

    Jasper Xian, Tommaso Teofili, Ronak Pradeep, and Jimmy Lin. 2024. Vector search with OpenAI embeddings: Lucene is all you need. In Proceedings of the 17th ACM International Conference on Web Search and Data Mining . 1090–1093

    2024

  39. [47]

    Qian Xu, Juan Yang, Feng Zhang, Junda Pan, Kang Chen, Youren Shen, Amelie Chi Zhou, and Xiaoyong Du. 2025. Tribase: A Vector Data Query Engine for Reliable and Lossless Pruning Compression using Triangle Inequalities. Proceedings of the ACM on Management of Data 3, 1 (2025), 1–28

    2025

  40. [48]

    Mingyu Yang, Wentao Li, Jiabao Jin, Xiaoyao Zhong, Xiangyu Wang, Zhitao Shen, Wei Jia, and Wei Wang. 2024. Effective and General Distance Computation for Approximate Nearest Neighbor Search. arXiv preprint arXiv:2404.16322 (2024)

    2024 arXiv

  41. [49]

    Xianzhi Zeng, Zhuoyan Wu, Xinjing Hu, Xuanhua Shi, Shixuan Sun, and Shuhao Zhang. 2024. CANDY: A Benchmark for Continuous Approximate Nearest Neighbor Search with Dynamic Data Ingestion. arXiv preprint arXiv:2406.19651 (2024)

    2024 arXiv

  42. [2019]

    Pattern Recognition 96 (2019), 106970

    Hierarchical clustering-based graphs for large scale approximate nearest neighbor search. Pattern Recognition 96 (2019), 106970

    2019

Pith tools

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