Live data from Hacker News

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

github.com

21–30 of 50 posts

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

#21
post #3

Are these sort of similarity searches useful for classifying text?

Embeddings are good at partitioning document stores at a coarse grained level, and they can be very useful for documents where there's a lot of keyword overlap and the semantic differentiation is distributed. They're definitely not a good primary recall mechanism, and they often don't even fully pull weight for their cost in hybrid setups, so it's worth doing evals for your specific use case.

"12+38" won't embed close to "50", as you said they capture only surface level words ("a lot of keyword overlap") not meaning, it's why for small scale I prefer a folder of files and a coding agent using grep/head/tail/Python one liners.

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

#23
I recently discovered https://www.cozodb.org/ which also vector search built-in. I just started some experiments with it but so far I'm quite impressed. It's not in active development atm but it seems already well rounded for what it is so depending on the use-case it does not matter or may even be an advantage. Also with today's coding agent it shouldn't be too hard to scratch your own itch if needed.

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

#24
post #3

Are these sort of similarity searches useful for classifying text?

Yes. This is known as a knn classifier. Knn classifiers are usually worse than other simple classifiers, but trivial to update and use.

See e.g., https://scikit-learn.org/stable/auto_examples/neighbors/plot...

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

#26
post #8

Their self-reported benchmarks have them out-performing pinecone by 7x in queries-per-second: https://zvec.org/en/docs/benchmarks/ I'd love to see those results independently verified, and I'd also love a good explanation of how they're getting such great performance.

Pinecone scales horizontally (which creates overhead, but accomodates more data).

A better comparison would be with Meta's FAISS

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

#27
post #14
post #8

Their self-reported benchmarks have them out-performing pinecone by 7x in queries-per-second: https://zvec.org/en/docs/benchmarks/ I'd love to see those results independently verified, and I'd also love a good explanation of how they're getting such great performance.

PGVectorScale claims even more. Also want to see someone verify that.

Exactly. We should always be asking these sort of questions and take these self-reported benchmarks with a grain of salt until independent sources can verify such claims rather than trusting results from the creators themselves. Otherwise it falls into biased territory.

This sort of behaviour is now absolutely rampant in the AI industry.

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

#28
post #8

Their self-reported benchmarks have them out-performing pinecone by 7x in queries-per-second: https://zvec.org/en/docs/benchmarks/ I'd love to see those results independently verified, and I'd also love a good explanation of how they're getting such great performance.

It is absolutely possible and even not so hard. If you use Redis Vector Sets you will easily see 20k - 50k (depending on hardware) queries per second, with tens of millions of entries, but the results don't get much worse if you scale more. Of course all that serving data from memory like Vector Sets do. Note: not talking about RedisSearch vector store, but the new "vector set" data type I introduced a few months ago. The HNSW implementation of vector sets (AGPL) is quite self contained and easy to read if you want to check how to achieve similar results.

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

#29
post #8

Their self-reported benchmarks have them out-performing pinecone by 7x in queries-per-second: https://zvec.org/en/docs/benchmarks/ I'd love to see those results independently verified, and I'd also love a good explanation of how they're getting such great performance.

Author here. Thanks for the interest! On the performance side: we've applied optimizations like prefetching, SIMD, and a novel batch distance computation (similar to a GEMV operation) that alone gives ~20% speedup. We're working on a detailed blog post after the Lunar New Year that dives into all the techniques—stay tuned!

And we always welcome independent verification—if you have any questions or want to discuss the results, feel free to reach out via GitHub Issues or our Discord.

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

#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!
Post reply on HN