codingjaguar

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.

(I'm from Milvus so i could be biased.)

This quite aligns with our observation at Milvus. Recently, we helped several users migrate from pgvector as the workload grew substantially.

It’s worth recognising the strengths of pgvector:

• For small-to-medium scale workloads (e.g., up to millions of vectors, relatively static data), embedding storage and similarity queries inside Postgres can be a simple, familiar architecture.

• If you already use Postgres and your vector workloads are light (low QPS, few dimensions, little metadata filtering / low concurrency), then piggy-backing vector search on Postgres is attractive: minimal added infrastructure.

• For teams that don’t want to introduce a separate vector service, or want to keep things within an existing RDBMS, pgvector is a compelling choice.

From our experience helping users scale vector search in production, several pain-points emerge when scaling vector workloads inside a general-purpose RDBMS like Postgres:

1. Index build / update overhead • Postgres isn’t built from the ground-up for high-velocity vector insertions plus large-scale approximate nearest neighbour (ANN) index maintenance, for example, lacking RaBitQ binary quantization supported in purpose built vector db like Milvus.

• For large datasets (tens/hundreds of millions or beyond), building or rebuilding HNSW/IVF indices inside Postgres can be memory- and time-intensive.

• In production systems where vectors are continuously ingested, updated, deleted, this becomes operationally tricky.

2. Filtered search

• Many use-cases require combining vector similarity with scalar/metadata filters (e.g., “give me top 10 similar embeddings where user_status = ‘active’ AND time > X”).

• Need to understand low level planner to juggle pre-filtering, post-filtering, and planner’s cost model wasn’t built for vector similarity search. For a system not designed primarily as a vector DB, this gets complex. Users shouldn't have to worry about such low level details.

3. Lack of support for full-text search / hybrid search

• Purpose built vector db such as Milvus has mature full-text search / BM25 / Sparse vector support.

Curious is that colbert-like ones?

The complex aggregations are indeed an important feature for sophisticated search products like e-commerce search with interactive filtering. There is probably no easy way for a vector db to catch up quick. But, - Most RAG and enterprise apps don't really need that level of sophistication in UX, what they need instead is simple and reliable infrastructure - Give vector db some time to catch up. Google Spanner didn't have any SQL capability at the early days, but they caught up after a few years, now with full SQL support. And SQL is probably more complex than Elasticsearch's aggregation.