Vector database choice is one of the decisions teams overthink most. Most production RAG systems would work fine on three or four of the popular options. The differences that matter at scale are usually operational — how the database behaves when you push it past 10M vectors, how hybrid search is implemented, how metadata filtering performs on real queries.
The options in 2026
pgvector
The default we recommend for projects starting today. You already have Postgres. Adding pgvector is an extension install. Your AI data lives next to your business data; joins work; backups work; permissions work. Scales cleanly to ~10M vectors on a reasonable instance. Above that, ingest and query performance degrade in ways that need tuning (IVFFlat vs HNSW indexes, work_mem, parallel workers).
When to pick pgvector: any project under 10M vectors with a Postgres-using team, any project where the simplicity of "one database" outweighs peak performance, any project where data gravity (joins, ACL inheritance, transactions) matters.
Qdrant
Our default when pgvector stops being enough. Rust-based, production-stable, hybrid search first-class, sensible clustering story. Self-hostable or managed. Strong filtering performance on high-cardinality metadata. The API is clean, the docs are good, the failure modes are predictable. Scales cleanly past 100M vectors.
Weaviate
Feature-rich, opinionated about schemas, more complex to operate than Qdrant. Generative-search features (Weaviate calls this "generative modules") are novel but we rarely use them in production — we prefer keeping retrieval and generation in separate layers. Good choice if you want managed hybrid search with a batteries-included feel.
Pinecone
Still the strongest managed option for teams that don't want to run anything. Serverless tier handles spiky workloads well; the dedicated tier handles steady high-throughput workloads. Pricing has improved since 2024 but remains the most expensive per million vectors among the serious options. Pick it when ops bandwidth is the constraint.
Milvus
The choice at extreme scale (100M+ vectors, high-throughput ingest). More operational overhead than the others — essentially requires a dedicated infra team to run well — but nothing else we've benchmarked handles multi-billion-vector workloads as cleanly.
What actually matters at production scale
Three things consistently separate well-running vector DBs from poorly-running ones in production, and most of them aren't about the database itself.
Hybrid search quality
Pure vector search is insufficient for most use cases. You want the database to support hybrid natively (BM25 + vector with ranked fusion) or to compose well with an external inverted index. Qdrant and Weaviate do this best; Pinecone has it but it's less polished; pgvector needs manual composition with Postgres' built-in text search. See our hybrid search post.
Metadata filter performance
Once you have millions of vectors, almost every real query filters by tenant ID, document type, date range, or similar. How the DB handles this matters more than its pure ANN speed. Qdrant's payload indexing is best-in-class here; pgvector inherits Postgres' general filter performance (excellent); Pinecone does fine but can get expensive at high filter cardinality.
Reindex speed
You will reindex. Embedding model upgrades, chunking changes, schema changes all force full reindexes. How long that takes and how you handle dual-write during transition determines whether reindexing is a Tuesday task or a weekend-long incident. Qdrant's snapshot/restore and pgvector's standard Postgres replication make this tractable.
Our recommendation
Default to pgvector until you have a concrete reason not to. Most projects never need more. When you need more, Qdrant is the best general-purpose next step. Pick Pinecone only when "I don't want to run anything" is a hard constraint. Pick Milvus only at extreme scale with dedicated infra.
One last point: never pick a vector DB based on a benchmark. Benchmark results are usually run on synthetic data without metadata filters, without hybrid search, and without your specific access patterns. Our benchmark of record is "can I build the system our client needs with this DB without burning a week on undocumented quirks?" That test reorders the rankings constantly.