pgvector, Milvus, Pinecone, Qdrant or Weaviate: a qualitative comparison, a decision tree and our own defaults, without benchmark theatre or vendor pricing tables that expire next quarter.
Start with what you already run, unless scale or ops says otherwise
The vector database is rarely what makes or breaks a search or RAG project. Chunking, embeddings and evaluation matter more. Pick the store that fits your hosting, scale and team, keep it behind a thin interface, and move on.
How to read this page
The table compares engines on the questions that actually come up in selection. The decision tree turns those into a path. The interactive chooser asks the same questions and ranks the options for you.
Extension inside PostgreSQL; self-host or any managed Postgres
Open source; self-host on Kubernetes or Docker, or a managed cloud option (Zilliz Cloud)
Fully managed service only, with a serverless option
Open source; self-host or managed cloud
Open source; self-host or managed cloud
Scale profile
Small to mid; bounded by a single Postgres instance
Very large; distributed architecture, GPU index options
Large; scaling handled by the vendor
Mid to large; sharding and replication
Mid to large; sharding and replication
Metadata filtering
Full SQL: WHERE, joins, transactions
Scalar field filtering
Metadata filters on each query
Rich payload filtering, including nested conditions
Property filters with a GraphQL-style query API
Hybrid / sparse support
Via Postgres full-text search; fuse in SQL or app
Sparse and dense vectors, hybrid search in the engine
Sparse-dense hybrid supported
Sparse vectors with server-side fusion
Built-in BM25 hybrid with a weighting parameter
Ops burden
Lowest if Postgres is already run
Highest when self-hosted (several components); low on managed
None beyond account and keys
Moderate; single binary, cluster optional
Moderate; single binary, cluster optional
Cost model
Your existing Postgres bill plus storage
Infrastructure you run, or managed usage
Usage-based managed pricing
Infrastructure you run, or managed usage
Infrastructure you run, or managed usage
Best fit
Apps already on Postgres with modest corpora
Large, multi-tenant or GPU-indexed workloads
Teams with no ops capacity who want it to just work
Filter-heavy workloads, self-host control
Hybrid out of the box, module ecosystem
Qualitative by design. Capabilities change with releases; we confirm current behaviour during the selection sprint. For a longer narrative comparison, read vector database comparison.
Decision tree
Four questions that settle most selections
Answer the questions top to bottom. A "yes" exits to the right; a "no" moves down. Most teams exit at the first or second question.
Two questions deliberately come before any feature comparison. What you already operate, and whether anyone can operate something new, eliminate more options than any capability matrix. Only after those do filtering, hybrid support and raw scale come into play.
Our defaults
What we reach for, and why
We run Milvus in production for our own products. It is our default when a workload is large, serves many tenants from one cluster, or benefits from GPU indexing. The managed Zilliz Cloud option is the route we suggest when a client wants Milvus without the Kubernetes work.
We use PostgreSQL with pgvector wherever a client's application already runs on Postgres and the corpus is modest. Vectors sit beside the rows they describe, permissions are a join, and there is one backup to worry about.
Pinecone, Qdrant and Weaviate all appear in our builds when the tree above points at them. The advice follows the workload, not a vendor preference.
Situation
Our usual pick
Existing Postgres app, under a few million vectors
pgvector
SaaS product, many tenants, growing fast
Milvus
Small team, no infrastructure engineers
Pinecone or a managed cloud
Strict residency, filter-heavy queries
Qdrant, self-hosted
Hybrid search wanted on day one, minimal code
Weaviate
Beyond the table
Questions a comparison grid cannot answer
The grid gets you to a shortlist. These are the questions we test during the selection sprint, with your data.
Filter selectivity
A filter that removes most of the index can make approximate search miss results. We test your real filters at your real cardinalities.
Update patterns
Bulk nightly loads and constant small updates stress engines differently. Deletions and re-embeds matter as much as inserts.
Multi-tenancy
One collection per tenant, a tenant field, or partitions: each engine has a preferred pattern and a limit on how many tenants it handles well.
Data residency
Region availability for managed options, and what leaves your network when you embed and query. See on-prem versus cloud.
Backup and restore
How you snapshot, how long restore takes, and whether you can rebuild from source documents instead.
Team skills
Who gets paged when the index is slow at 2 a.m.? The engine your team can debug beats the engine with the best chart.
Switchable by design
Make the choice reversible
Every build we deliver puts the store behind a thin retrieval interface: upsert, query with filters, delete, and a health check. Application code never speaks a vendor's query language directly. Document IDs, chunk text and metadata are kept in your system of record, and vectors are treated as a derived cache that can be regenerated.
With that in place, moving from pgvector to Milvus, or from a managed service to a self-hosted engine, is a re-index job measured in days. It follows the same versioning plan described under embeddings strategy. The evaluation harness confirms nothing regressed before traffic switches.
Retrieval interface with four operations, implemented once per engine
Chunk text and metadata stored outside the vector index
Stable document and chunk IDs shared across engines
Export and re-index scripts kept in the repository
Evaluation set run against old and new before cut-over
Process
The selection sprint
Constraints (days 1–2)
Hosting, residency, scale now and in two years, update patterns, filters, team capacity, budget sensitivity.
Shortlist (day 3)
Two engines, at most three, chosen with the tree and the questions above. Written reasons for every exclusion.
Proof on your data (days 4–8)
A representative slice indexed in each candidate, with your filters and your labelled queries. Latency, recall and operational notes recorded.
Recommendation (days 9–10)
A decision memo, the retrieval interface, infrastructure notes and a cost outline, ready to feed the build.
One to two weeks, fixed scope. The memo is written so that someone outside the project can follow the reasoning. That is what a fractional AI CTO or an architecture board will ask for. Definitions for the terms used throughout are in the glossary.
Often not at first. If your application already runs on PostgreSQL and your corpus is well under tens of millions of vectors, pgvector keeps vectors, metadata and transactions in one place. Dedicated engines earn their place at larger scale, with heavy filtering, or when you need features a Postgres extension does not offer.
Which vector database do you recommend?
The one that matches your hosting constraints, scale and team. We run Milvus in production and use PostgreSQL with pgvector where Postgres already exists, so those are our defaults. Pinecone, Qdrant and Weaviate are all sound choices for the situations described on this page.
Are managed vector databases safe for sensitive data?
They can be, subject to region, encryption, access controls and your contractual position. The question is the same as for any managed database. Our AI data privacy service covers the assessment; where residency rules are strict, self-hosting an open-source engine is the usual answer.
How hard is it to switch vector databases later?
Straightforward if the retrieval layer is a thin interface and the source documents still exist. Vectors can be regenerated; what you must preserve is the chunking, metadata and document IDs. We design every build so a switch is a re-index job, not a rewrite.
Why no benchmark numbers on this page?
Published benchmarks depend on dataset, hardware, index settings and the version tested, and they go stale fast. We run a small proof on your data during the selection sprint, which tells you more than any public chart.
Ready to make AI work in production?
Tell us about your systems, your data and your constraints. We reply within one business day with a straight answer and a suggested next step.