useful 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)
Re:zvec: embedded vector database
by NitpickLawyer on Sunday February 15, 2026 @02:01AM
(#47021652)
These engagement bots are getting tiresome...
Re:zvec: embedded vector database
by dev_l1x_be on Sunday February 15, 2026 @03:20AM
(#47021991)
i 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.
The appeal of in-process is obvious — no network hop, simpler deployment, lower latency on small-to-medium datasets. But I'm curious about the operational story. How do you handle index updates while serving queries? Is there a write lock during re-indexing, or can you do hot swaps?
The mceachen comment about sqlite-vec being brute-force is interesting too. For apps with under ~100K embeddings, does the algorithmic difference even matter practically, or is the simpler deployment story more important than raw QPS?