It seems to me like many developers are moving from native vector stores back to Postgres with pgvector. It's easier to integrate, cheaper to set up, familiar to work with, oftentimes faster, while not hitting any limitations for most projects. My vector store recommendation boils down to: "Use pgvector unless you have specific reason not to".
well it's apples and oranges. Why do people buy F150 instead of fitting things into the trunk of a Corolla? cuz they got a lot of stuff.
For people who run thousands of QPS on billions of vectors, Milvus is a solid choice. For someone playing with a twitter demo with a few thousand vectors, any vector db can do the job well. In fact there is a fun project Milvus Lite designed for that case :)
I've seen many builders migrate from pgvector to Milvus as their apps scale. But perhaps they wish they had considered scalability earlier.
People buy F150s because they find them cool and not because they actually need the space. Your Corolla could make deliveries around town in roughly the same time, while being cheaper and easier compared to introducing a new expensive car. In situations you need more space (which most of us won't), you can add a trailer instead.
pgVector is great and so is FAISS, but those are just a subset of what you get from Milvus. If all you need to do is RAG over 50Mb of documents then pick the right tool for the job. I use Chroma for a lot of projects.
Then, what if you want hybrid search, or different IVF variants, or disk-based search, or horizontal scaling, or something that leverages SIMD, or sparse vectors? Milvus is great.
The repo includes plpgsql_bm25rrf.sql : PL/pgSQL function for hybrid search ( plpgsql_bm25 + pgvector ) with Reciprocal Rank Fusion; and Jupyter notebook examples.
You start by underselling what can be done with Postgres and then follow up with the upper end of requirements that most projects won't need. My argument is exactly what you conveniently left out: The big bulk between the two.
Does this still hold?
reply