pgvector is enough for small datasets, not your default

Under 100K vectors, pgvector is enough; beyond that, dedicated vector databases win on latency.

pgvector in PostgreSQL is the right default for small vector workloads, and the 1bench ranking reinforces that by putting dedicated systems like Qdrant, Milvus, and Weaviate ahead only when the workload starts demanding serious ANN performance.

First argument: most teams are overbuying vector infrastructure

The simplest proof is in the benchmark’s own summary: if your dataset stays under 100K vectors, PostgreSQL with pgvector is often sufficient. That is not a niche case. It is the common case for internal search, prototype RAG, product discovery on a narrow catalog, and early-stage semantic retrieval.

Once you accept that, the economics change fast. PostgreSQL already gives you transactions, backups, access control, SQL joins, and operational familiarity. Adding pgvector keeps the stack small and the team moving. A dedicated vector database only pays for itself when the retrieval layer becomes the product bottleneck, not when you are still validating whether vector search belongs in the product at all.

Second argument: dedicated vector databases earn their keep on scale and latency

1bench ranks Milvus, Qdrant, and Weaviate near the top because they are built for the job, not adapted to it. Milvus sits at 45.2k GitHub stars, Qdrant at 33.3k, and Weaviate at 16.6k, which is a useful proxy for ecosystem maturity and adoption. More importantly, these systems are purpose-built for indexing, filtering, and nearest-neighbor search under load.

That matters when latency targets get strict and the vector count climbs into the millions. A general-purpose database can store embeddings, but a dedicated engine is designed to optimize ANN structures, memory layout, and query execution around similarity search. If your product promise depends on fast top-k retrieval across a large corpus, pgvector becomes a compromise and not a strategy.

Third argument: the best choice is shaped by product architecture, not hype

The ranking also shows that “vector database” is now a loose label. Redis, Meilisearch, Typesense, MongoDB, and even AliSQL all appear because teams are mixing semantic search into broader systems. That is the real pattern: many applications do not need a standalone vector store, they need vector capability inside a system they already run.

For engineers, that means the decision is architectural. If embeddings are a feature inside a relational app, PostgreSQL is a clean fit. If semantic retrieval is the core path, or if you need hybrid search, multimodal retrieval, or distributed scale, then a dedicated system like Qdrant, Milvus, Weaviate, or Vespa is the correct layer. The point is not to use the fanciest database. The point is to place the vector workload where it belongs.

The counter-argument

The strongest case against pgvector is that “good enough” often becomes technical debt. Dedicated vector databases offer specialized indexing, better horizontal scaling, and features that PostgreSQL does not natively prioritize, including hybrid retrieval, filtering tuned for ANN, and operational patterns designed around embeddings from day one. If a team knows it will grow, starting with the purpose-built option avoids a migration later.

There is also a developer-experience argument. Teams adopting AI features today want a system that speaks the language of embeddings, similarity search, and RAG out of the box. A dedicated vector database reduces glue code and makes intent obvious. That is a real advantage, especially when the team is small and the product roadmap is already crowded.

Still, that counter-argument only wins when scale is already visible. If the corpus is small, the query volume is modest, and the team already operates PostgreSQL, the migration cost and extra moving parts are real. The right move is not to preemptively optimize for a future you have not earned yet. Start with pgvector, measure latency and recall, then graduate only when the numbers force you to.

What to do with this

If you are an engineer, default to PostgreSQL with pgvector until your corpus, latency SLOs, or hybrid-search needs clearly exceed what a single relational stack can handle. If you are a PM or founder, treat a dedicated vector database as an infrastructure purchase tied to a measurable retrieval problem, not as an AI badge. Choose Qdrant, Milvus, or Weaviate when vector search is central; choose pgvector when it is just one feature in a broader product.