4 ms·
Zvec: A lightweight, fast, in-process vector database
https://zvec.org/en/ https://zvec.org/en/
- clemlesne 8mo agoDid someone compared with uSearch (https://github.com/unum-cloud/USearch https://github.com/unum-cloud/USearch)?
- neilellis 8mo agoThat I would like to see too, usearch is amazingly fast, 44m embeddings in < 100ms
- skybrian 8mo agoAre these sort of similarity searches useful for classifying text?
- OutOfHere 8mo agoIt altogether depends on the quality and suitability of the provided embedding vector that you provide. Even with a long embedding vector using a recent model, my estimation is that the classification will be better than random but not too accurate. You would typically do better by asking a large model directly for a classification. The good thing is that it is often easy to create a small human labeled dataset and estimate the error confusion matrix via each approach.
- CuriouslyC 8mo agoEmbeddings 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.
- visarga 8mo ago"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.
- esafak 8mo agoYou could assign the cluster based on what the k nearest neighbors are, if there is a clear majority. The quality will depend on the suitability of your embeddings.
- neilellis 8mo agoYes, also for semantic indexes, I use one for person/role/org matches. So that CEO == chief executive ~= managing director good when you have grey data and multiple look up data sources that use different terms.
- stephantul 8mo agoYes. 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_classification.html https://scikit-learn.org/stable/auto_examples/neighbors/plot...
- _pdp_ 8mo agoI thought you need memory for these things and CPU is not the bottleneck?
- binarymax 8mo agoI haven’t looked at this repo, but new techniques taking advantage of nvme and io_uring make on disk performance really good without needing to keep everything in RAM.
- simonw 8mo agoTheir self-reported benchmarks have them out-performing pinecone by 7x in queries-per-second: https://zvec.org/en/docs/benchmarks/ 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.
- ashvardanian 8mo ago8K QPS is probably quite trivial on their setup and a 10M dataset. I rarely use comparably small instances & datasets in my benchmarks, but on 100M-1B datasets on a larger dual-socket server, 100K QPS was easily achievable in 2023: https://www.unum.cloud/blog/2023-11-07-scaling-vector-search-with-intel https://www.unum.cloud/blog/2023-11-07-scaling-vector-search... ;) Typically, the recipe is to keep the hot parts of the data structure in SRAM in CPU caches and a lot of SIMD. At the time of those measurements, USearch used ~100 custom kernels for different data types, similarity metrics, and hardware platforms. The upcoming release of the underlying SimSIMD micro-kernels project will push this number beyond 1000. So we should be able to squeeze a lot more performance later this year.
- luoxiaojian 8mo agoAuthor here. Appreciate the context—just wanted to add some perspective on the 8K QPS figure: in the VectorDBBench setting we used (10M, 768d, on comparable hardware to the previous leader), we're seeing double their throughput—so it's far from trivial on that playing field. That said, self-reported numbers only go so far—it'd be great to see USearch in more third-party benchmarks like VectorDBBench or ANN-Benchmarks. Those would make for a much more interesting comparison! On the technical side, USearch has some impressive work, and you're right that SIMD and cache optimization are well-established techniques (definitely part of our toolbox too). Curious about your setup though—vector search has a pretty uniform compute pattern, so while 100+ custom kernels are great for adapting to different hardware (something we're also pursuing), I suspect most of the gain usually comes from a core set of techniques, especially when you're optimizing for peak QPS on a given machine and index type. Looking forward to seeing what your upcoming release brings!
- 8mo ago
- cjonas 8mo agoHow does this compare to duckdbs vector capabilities (vss extension)?
- jgalt212 8mo agoYes, nothing on that or sqlite-vec (both of which seem to be apples to apples comparisons). https://zvec.org/en/docs/benchmarks/ https://zvec.org/en/docs/benchmarks/
- mceachen 8mo agoI 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 algorithm in sqlite-vec.
- luoxiaojian 8mo agoYou'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 GIST.
- OfficialTurkey 8mo agoI haven't been following the vector db space closely for a couple years now, but I find it strange that they didn't compare their performance to the newest generation serverless vector dbs: Pinecone Serverless, turbopuffer, Chroma (distributed, not the original single-node implementation). I understand that those are (mostly) hosted products so there's not a true apples-to-apples comparison with the same hardware, but surely the most interesting numbers are cost vs performance.
- wittlesus 8mo ago[dead]
- yawnxyz 8mo agouseful for adding semantic search to tiny bits of data, e.g. collections of research papers in a folder on my computer, etc. for web stuff, e.g. community/forums/docs/small sites which usually don't even have 1M rows of data, precomputing embeddings and storing them and running on a small vector search like this somewhere is much simpler/cheaper than running external services it's the operational hassle of not having to deal with a dozen+ external services, logins, apis, even if they're free (I do like mixed bread for that, but I'd prefer it to be on my own lightweight server or serverless deployment)
- NitpickLawyer 8mo agoThese engagement bots are getting tiresome...
- dev_l1x_be 8mo agoi think the question is really: can I turn my search problem into a in-process vector search problem where I can scale with the number of processes.
- newzino 8mo ago[flagged]
- deleted 8mo ago[deleted]
- aktuel 8mo agoI recently discovered https://www.cozodb.org/ 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.
- cmrdporcupine 8mo agocozodb is quite impressive and I've wondered about the funding sources etc on it, if any. I've watched it for some years and the developer seems to have made a real passion project out of it but you're right it seems development has tapered off.
- luoxiaojian 8mo agoAuthor 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!
- jtwebman 8mo agoCan you add Postgres with PVector?
- luoxiaojian 8mo agoWill do—pgvector is on our list for the blog post.
- dmezzetti 8mo agoVery interesting! It would be great to see how it compares to Faiss / HNSWLib etc. I'd will consider integrating it into txtai as an ANN backend.
- miga 8mo agoWhy no benchmarks against pg_vector, DuckDB with extension? For benchmarks you may just prepare Phoronix Test Suite module (https://www.phoronix-test-suite.com/ https://www.phoronix-test-suite.com/) to facilitate replication on a variety of machines.
- qaqqqqaq 8mo ago[dead]
- asura5758 8mo agoHi, since this is in process, I wonder what is the memory requirement to run this for e.g. serving 1TB vector data (I have this in pgvector for now) data for example?
- arlogilbert 8mo agoJust 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.
- luoxiaojian 7mo agoAuthor 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.
- luoxiaojian 7mo agoIf 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!