Vector database comparison: pgvector, Milvus, Pinecone, Qdrant and Weaviate

Why this choice matters less, and more, than you think

A vector database stores the embeddings of your documents and finds the nearest ones to a query. Every serious option does that well. If your RAG system performs badly, the vector store is rarely the reason. Chunking, embeddings and retrieval logic matter far more, as we explain in RAG explained.

So why does the choice matter at all? Because it decides three things you will live with for years: where your data physically sits, who carries the operational burden, and how much friction you face when the collection grows tenfold. Those are infrastructure decisions, and infrastructure decisions are expensive to reverse.

Our position is simple. Start with the least new infrastructure that meets the requirements, and only add a dedicated engine when a specific requirement forces you to. For most teams that means starting with PostgreSQL.

The criteria that actually decide it

Vendor comparison pages list dozens of features. In practice, six questions settle the decision.

• Scale. How many vectors, at what dimensionality, growing how fast? A few million vectors fit on one well-sized database node. Hundreds of millions do not.
• Latency and concurrency. Is this an internal tool with a handful of users or a customer-facing product with thousands of concurrent queries and a strict response budget?
• Filtering. Will almost every query carry filters such as tenant, permission group, date or document type? Filtered search is where engines differ most in practice.
• Hybrid search. Do you need keyword and vector results merged in one query? Hybrid search is close to mandatory for anything with product codes, names or legal references.
• Hosting and residency. Must data stay in a specific region or on your own hardware? That rules managed-only services in or out immediately.
• Operations. Who upgrades it, backs it up, monitors it and gets paged at 3 a.m.? A distributed engine is a real system to run.

Notice what is absent: raw query speed on a public benchmark. Benchmarks measure a configuration you will not run, on data you do not have. Measure on your own queries or not at all.

A decision tree

The tree below is how we start most conversations. It is deliberately biased towards less infrastructure.

Two caveats. First, "fully managed" is available for every option on this page through a vendor cloud, so the Pinecone branch really means "I want a service, not a system". Second, every branch assumes you have an embedding model chosen already; the database does not fix a poor one.

The five contenders

pgvector

An open-source extension that adds vector columns, distance operators and approximate indexes to PostgreSQL. Its strength is that it is not a new system. Vectors sit next to the rows they describe, filters are ordinary WHERE clauses, backups and permissions already exist, and full-text search gives you hybrid retrieval with a join. Its limit is the limit of a single database node; past that you are sharding PostgreSQL, which is not what it was built for. We cover sizing in our pgvector service.

Milvus

An open-source, distributed vector engine designed for very large collections. It separates storage from compute, supports several index types and scales horizontally. It is also a genuine distributed system with several components, so it needs operational investment or a managed offering. We reach for it when the collection or the latency target has outgrown everything simpler, and describe that work on our Milvus page.

Pinecone

A fully managed service with no self-hosted option. You get an API, metadata filtering, namespaces for tenancy and none of the operations. The trade-offs are the usual ones for managed services: your data lives in the vendor's cloud in the regions they offer, costs scale with usage, and you cannot run it inside your own perimeter. Right for teams that want to spend engineering time elsewhere; see our Pinecone page.

Qdrant

An open-source engine written for filtered vector search. Its payload filtering is expressive and efficient, it supports sparse vectors for hybrid retrieval, and it runs as a single binary or a cluster, self-hosted or managed. It is a good middle ground when PostgreSQL is not the answer but a full distributed deployment is more than you need.

Weaviate

An open-source engine with hybrid search built into the query layer, native multi-tenancy and an optional module system that can call embedding models for you. It suits teams that want keyword and vector retrieval merged by default and value the richer object model. Self-host or managed. We cover both in Qdrant and Weaviate.

Side by side

The table summarises how we characterise each option in client work. It reflects typical deployments rather than every feature a vendor lists.

Feature sets move quickly in this market, so treat the table as a starting position and verify current capabilities before you commit. The questions in the criteria section change far more slowly than the products.

Pitfalls we see

Plan for migration from day one

Whatever you pick, assume you will change it. Collections grow, vendors change pricing models, residency rules tighten. Three habits keep that change cheap.

First, keep chunks and metadata in a store you control, such as the same PostgreSQL or an object store, and treat the vector index as derived data. Second, put retrieval behind one interface in your code so that swapping engines touches a single module. Third, keep the evaluation set from evaluating LLM outputs current, so you can prove the new engine returns the same passages before you cut over.

Done this way, a migration from pgvector to Milvus is a re-index and a regression run. Done the other way, it is a rewrite with a weekend of downtime.

Our default recommendation

Start on pgvector unless one of the branches in the tree forces you elsewhere. Build the retrieval layer, the hybrid search and the evaluation set on it. If the collection or the latency target outgrows a single node, move to Milvus or a managed engine with that evidence in hand. The teams who regret their vector database choice are almost always the ones who chose a large system for a small problem, not the reverse.

If you want the decision made against your actual numbers, our vector database selection engagement does exactly that, usually in a week.

Key takeaways

• Every credible vector database finds nearest neighbours well; the decision is about scale, hosting and operations.
• Six questions decide it: scale, latency, filtering, hybrid search, residency, and who runs it.
• pgvector is the right default for most teams already on PostgreSQL.
• Milvus earns its complexity only at very large scale or strict latency targets.
• Pinecone trades control for zero operations; Qdrant and Weaviate sit between.
• Test with your own data and your production filters, never with a public benchmark.
• Keep chunk text outside the vector store and retrieval behind one interface so you can migrate.

Related services