Vector databases: Pinecone vs Qdrant vs Weaviate vs pgvector vs Milvus#
The five most-cited stores for embedding-based retrieval. RAG architecture interviews ask "which one would you pick and why" almost every time.
Side-by-side#
| Pinecone | Qdrant | Weaviate | pgvector | Milvus | |
|---|---|---|---|---|---|
| Source / hosting | closed-source SaaS only | open-source (Rust) + managed cloud | open-source (Go) + managed cloud | Postgres extension | open-source (Go/C++) + Zilliz cloud |
| Primary index | proprietary (graph + DiskANN-style) | HNSW + Quantization | HNSW + flat | HNSW (also ivfflat) | HNSW, IVF, DiskANN, GPU IVF |
| Quantization | scalar, binary | scalar, binary, product | binary | none built-in | scalar, binary, product |
| Hybrid search (dense + sparse) | yes (separate index) | yes (native fusion) | yes (native BM25 + vectors) | yes (with tsvector) |
yes (since 2.4) |
| Filtering | post-filter | pre-filter with rich payload conditions | pre-filter | full SQL WHERE |
pre-filter |
| Multi-tenancy | namespaces | tenants + per-collection isolation | per-tenant collections + sharding | schemas + RLS | partitions + databases |
| Sharding | transparent (managed) | manual + auto sharding | sharding by class | none native (use Citus) | transparent, sharded by default |
| Operations | none (fully managed) | medium (Helm, K8s) | medium (Helm, K8s) | none extra (you run Postgres) | high (multiple components) |
| Cost shape | per-pod or serverless per-query | per-node + storage | per-node + storage | bundled with Postgres | per-node + GPU |
| Where it shines | hands-off RAG, fast PoC | rich filters, hybrid, self-host | knowledge-graph + vectors | already-have-Postgres apps | billions of vectors, GPU recall |
Quick chooser#
flowchart TB
Q[Pick a vector DB]
Q --> A{Already running Postgres<br/>and under 10M vectors?}
A -->|yes| PG[pgvector]
A -->|no| B{Need hands-off SaaS,<br/>no ops budget?}
B -->|yes| PC[Pinecone]
B -->|no| C{Need GPU-accelerated ANN<br/>for 100M+ vectors?}
C -->|yes| ML[Milvus]
C -->|no| D{Need knowledge-graph<br/>+ vectors in one store?}
D -->|yes| WV[Weaviate]
D -->|no| QD[Qdrant]
classDef p fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
classDef s fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
class Q,A,B,C,D p;
class PG,PC,ML,WV,QD s;
Pick by access pattern#
| Access pattern | Pick |
|---|---|
| RAG over private docs, < 5M chunks, AWS / GCP | Pinecone (serverless) |
| RAG over private docs, 5-50M chunks, want self-host | Qdrant |
| Semantic search with structured filter (region, tier, tenant) | Qdrant |
| Already-have-Postgres app, want vectors next to SQL data | pgvector |
| Multi-tenant SaaS, one tenant per collection / class | Weaviate |
| 100M+ vectors, GPU available, latency-critical | Milvus |
| Recommendation system, billions of items | Milvus + IVF-PQ |
| Knowledge-graph augmented retrieval (entities + vectors) | Weaviate |
| Hybrid search (BM25 + dense) as the default behaviour | Qdrant or Weaviate |
| Building on Vercel / Supabase / Neon | pgvector (managed Postgres) |
Gotchas you should know#
- Pinecone: post-filtering means high-selectivity filters can return fewer than
top_kresults; serverless billing per query can surprise you at million-RPS workloads; no on-prem option for regulated data. - Qdrant: pre-filter cardinality matters; very-selective filters can cause the graph index to fall back to brute force; payload indexes need to be defined explicitly for filter speed.
- Weaviate: schema-first means class-level changes need versioned migrations; the bundled BM25 is fine but not Lucene-grade; sharding rebalance is a manual operation.
- pgvector: HNSW build time on a single Postgres node is the bottleneck; large datasets need partitioning + Citus; no native quantization, so memory grows linearly with vectors.
- Milvus: multiple components (coordinator, query nodes, data nodes) means more ops; GPU index requires careful resource planning; smaller community than Postgres or Elasticsearch.
Where each appears in this site#
- ANN index internals: see Vector Databases for HNSW, IVF, PQ, and the math behind embedding similarity.
- The retrieval pipeline that sits on top of these: RAG Patterns.
- The ingestion side: Embedding Pipeline at Scale and Chunking Strategies.
- Re-ranking the candidates a vector DB returns: Reranking.
Glossary & fundamentals#
| Tag | Concept | Page |
|---|---|---|
HLD |
Vector database internals (HNSW, IVF, PQ) | vector-databases |
AI |
RAG patterns (naive, hybrid, HyDE, GraphRAG) | rag-patterns |
AI |
Chunking strategies for the index | chunking-strategies |
AI |
Embedding ingestion at scale | embedding-pipeline-scale |
AI |
Reranking after vector retrieval | reranking |
HLD |
Sharding strategies for any data store | database-sharding |
FAQ#
Which vector database should I pick for a RAG application?#
For under 10M vectors with a Postgres app already in place, pgvector. For a hands-off managed product, Pinecone. For self-hosted with rich filters and hybrid search, Qdrant or Weaviate. For 100M+ vectors with GPU acceleration, Milvus.
What is the difference between Pinecone and Qdrant?#
Pinecone is closed-source SaaS with serverless billing and no ops; Qdrant is open-source Rust with a managed cloud option, payload-rich filtering, and lower cost per vector at scale. Pinecone is easier; Qdrant is more flexible.
Can I use Postgres pgvector instead of a dedicated vector database?#
Yes, up to roughly 10M vectors with HNSW indexes and reasonable filter cardinality. Beyond that, recall and latency degrade; a dedicated vector DB with horizontal sharding wins. Use pgvector when you already have Postgres and want one less system.
What is hybrid search and which vector DBs support it?#
Hybrid search combines dense vector similarity (ANN) with sparse keyword scoring (BM25) and merges them with Reciprocal Rank Fusion. Qdrant, Weaviate, Milvus, and pgvector (with extensions) support it natively; Pinecone has a hybrid index type but with extra config.
What is the difference between HNSW and IVF-PQ?#
HNSW (Hierarchical Navigable Small World) is a graph index with high recall and low query latency, but higher memory. IVF-PQ (Inverted File + Product Quantization) compresses vectors aggressively and scales to billions, trading recall for storage. Pick HNSW for under 100M vectors, IVF-PQ for billions.
How do I decide between self-hosted and managed vector database?#
Self-hosted (Qdrant, Weaviate, Milvus) gives lower per-vector cost at large scale and data residency, but you own ops. Managed (Pinecone, Weaviate Cloud, Qdrant Cloud) is faster to start, predictable billing, no upgrade pain. Cross over usually happens around 50M vectors or strict compliance needs.
Further reading#
- 📄 Paper: Approximate Nearest Neighbor Search via HNSW (Malkov & Yashunin)
- 📄 Paper: Product Quantization for Nearest Neighbor Search (Jegou et al)
- 📑 Docs: Pinecone architecture overview
- 📑 Docs: Qdrant indexing internals
- 📑 Docs: Weaviate indexing and search
- 📑 Docs: pgvector HNSW notes
- ✍️ Blog: Milvus 2.4 release on GPU IVF and DiskANN