Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zvec: A lightweight, fast, in-process vector database

github.com

Post reply on HN
Print view View original

41–50 of 50 posts

Re: Zvec: A lightweight, fast, in-process vector database

#41

Post by luoxiaojian »

antirez wrote: post #35
luoxiaojian wrote: post #33

Earlier quoted context omitted.

Author here. Thanks for sharing—always great to see different approaches in the space. A quick note on QPS: throughput numbers alone can be misleading without context on recall, dataset size, distribution, hardware, distance metric, and other relevant factors. For example, if we relaxed recall constraints, our QPS would also jump significantly. In the VectorDBBench results we shared, we made sure to maintain (or exce…

Yep you are right, also: quantization is a big issue here. For instance int8 quantization has minimal effects on recall, but makes dot-product much faster among vectors, and speedups things a lot . Also the number of components in the vectors make a huge difference. Another thing I didn't mention is that for instance Redis implementation (vector sets) is threaded, so the numbers I reported is not about a single core.…

Appreciate the thoughtful breakdown—you're absolutely right that quantization, dimensionality, and threading all play a big role in performance numbers. Thanks for the kind words and for engaging in the discussion. Wishing you a happy Year of the Horse—新春快乐，马年大吉！

Re: Zvec: A lightweight, fast, in-process vector database

#43

Post by luoxiaojian »

jtwebman wrote: post #36
luoxiaojian wrote: post #30

Author here. Thanks everyone for the interest and thoughtful questions! I've noticed many of you are curious about how we achieved the performance numbers and how we compare to other solutions. We're currently working on a detailed blog post that walks through our optimization journey—expect it after the Lunar New Year. We'll also be adding more benchmark comparisons to the repo and blog soon. Stay tuned!

Can you add Postgres with PVector?

Will do—pgvector is on our list for the blog post.

Re: Zvec: A lightweight, fast, in-process vector database

#44

Post by mceachen »

luoxiaojian wrote: post #39
mceachen wrote: post #17

Earlier quoted context omitted.

I maintain a fork of sqlite-vec (because there hasn't been activity on the main repo for more than a year): sqlite-vec is great for smaller dimensionality or smaller cardinality datasets, but know that it's brute-force, and query latency scales exactly linearly. You only avoid full table scans if you add filterable columns to your vec0 table and include them in your WHERE clause. There's no probabilistic lookup algor…

You're absolutely right—sqlite-vec currently only supports brute-force search, and its latency does scale linearly with dataset size. We did some rough comparisons using its benchmark tools: on the SIFT dataset, latency was around 100ms; on GIST, it was closer to 1000ms. In contrast, with zvec's HNSW implementation, we get ~1ms latency on SIFT and ~3ms on GIST, while achieving recall@100 of 99.9% on SIFT and 97.7% on…

FWIW "You're absolutely right" broadly declares "a human is not piloting the keyboard"

Re: Zvec: A lightweight, fast, in-process vector database

#46

Post by jgalt212 »

mceachen wrote: post #44
luoxiaojian wrote: post #39

Earlier quoted context omitted.

You're absolutely right—sqlite-vec currently only supports brute-force search, and its latency does scale linearly with dataset size. We did some rough comparisons using its benchmark tools: on the SIFT dataset, latency was around 100ms; on GIST, it was closer to 1000ms. In contrast, with zvec's HNSW implementation, we get ~1ms latency on SIFT and ~3ms on GIST, while achieving recall@100 of 99.9% on SIFT and 97.7% on…

FWIW "You're absolutely right" broadly declares "a human is not piloting the keyboard"

You are undoubtedly correct!

Re: Zvec: A lightweight, fast, in-process vector database

#48

Post by arlogilbert »

Just put Zvec vs LanceDB vs Qdrant through the paces on a 3 collection (text only) 10k per collection dataset.

Average latency across ~500 queries per collection per database:

Qdrant: 21.1ms LanceDB: 5.9ms Zvec: 0.8ms

Both Qdrant and LanceDB are running with Inverse Document Frequency enabled so that is a slight performance hit, Zvec running with HNSW.

Overlap of answers between the 3 is virtually identical with same default ranking.

So yes, Zvec is incredible, but the gotcha is that the reason zvec is fast is because it is primarily constrained by local disk performance and the data must be local disk, meaning you may have a central repository storing the data, but every instance running zvec needs to have a local (high perf) disk attached. I mounted blobfuse2 object storage to test and zvec numbers went to over 100ms, so disk is almost all that matters.

My take? Right now the way zvec behaves, it will be amazing for on-device vector lookups, not as helpful for cloud vectors.

Re: Zvec: A lightweight, fast, in-process vector database

#49

Post by luoxiaojian »

arlogilbert wrote: post #48

Just put Zvec vs LanceDB vs Qdrant through the paces on a 3 collection (text only) 10k per collection dataset. Average latency across ~500 queries per collection per database: Qdrant: 21.1ms LanceDB: 5.9ms Zvec: 0.8ms Both Qdrant and LanceDB are running with Inverse Document Frequency enabled so that is a slight performance hit, Zvec running with HNSW. Overlap of answers between the 3 is virtually identical with same…

Author here. Thanks for putting Zvec through its paces and sharing such detailed results—really appreciate the hands-on testing!

Just a bit of context on the storage behavior: Zvec currently uses memory-mapped files (mmap) by default, so once the relevant data is warmed up in the page cache, performance should be nearly identical regardless of whether the underlying storage is local disk or object storage—it's essentially in-memory at that point. The 100ms latency you observed with blobfuse2 likely reflects cold reads (data not yet cached), which can be slower than local disk in practice. Our published benchmarks are all conducted with sufficient RAM and full warmup, so the storage layer's latency isn't a factor in those numbers.

Re: Zvec: A lightweight, fast, in-process vector database

#50

Post by luoxiaojian »

arlogilbert wrote: post #48

Just put Zvec vs LanceDB vs Qdrant through the paces on a 3 collection (text only) 10k per collection dataset. Average latency across ~500 queries per collection per database: Qdrant: 21.1ms LanceDB: 5.9ms Zvec: 0.8ms Both Qdrant and LanceDB are running with Inverse Document Frequency enabled so that is a slight performance hit, Zvec running with HNSW. Overlap of answers between the 3 is virtually identical with same…

If you're interested in query performance on object storage, we're working on a buffer pool–based I/O mode that will leverage io_uring and object storage SDKs to improve cold-read performance. The trade-off is that in fully warmed‑up, memory‑rich scenarios, this new mode may be slightly slower than mmap, but it should offer more predictable latency when working with remote storage. Stay tuned—this is still under development!
Post reply on HN