News for hackers. Stuff that matters.

A comment on Why HNSW is not the answer and disk-based alternatives might be more practical. Parent comment

Re:Why HNSW is not the answer and disk-based alternatives mi... by wild_egg on Monday December 23, 2024 @11:00PM (#42499647)
I've been using DuckDB similarly and loving the simplicity. What sort of latency are you seeing with your setup? I'm hitting 300ms to query against 10M vectors and could see that becoming a bottleneck if going into the hundreds of millions.
[ Parent | on HN ]
Re:Why HNSW is not the answer and disk-based alternatives mi... by VoVAllen on Monday December 23, 2024 @11:07PM (#42499669)
Hi, I'm the author of the article. Please check out our vector search extension in postgres, VectorChord [1]. It achieves 10ms-level latency for top-10 searches on a 100M dataset and 60ms-level latency when using SSD with limited memory.

[1] https://blog.pgvecto.rs/vectorchord-store-400k-vectors-for-1...

[ Parent | on HN ]
Re:Why HNSW is not the answer and disk-based alternatives mi... by wild_egg on Tuesday December 24, 2024 @04:27PM (#42505056)
Look like very nice tech but unfortunately the operational overhead of postgres is too high for my use case. Will keep it in mind for future postgres-backed projects though
[ Parent | on HN ]
Re:Why HNSW is not the answer and disk-based alternatives mi... by ashvardanian on Tuesday December 24, 2024 @03:59AM (#42500641)
DuckDB also uses USearch and the underlying SimSIMD library for kernels, but both were originally designed for a Billion+ scale.

Depending on how the wrapper is implemented you can get different numbers. With the raw libraries, on larger machines, I'd expect 200'000 requests per second for 1 Billion entries.

[ Parent | on HN ]