Every RAG system needs somewhere to store and search embeddings, and the choice matters more for your operational life than your answer quality. The good news: you probably don't need the fanciest option. This is a practical comparison of the three most common choices — pgvector, Pinecone, and Qdrant — plus when each is the right call.
All three retrieve well. The real differences are operational: managed vs self-hosted, scaling ceiling, filtering/hybrid features, and cost. Pick for how you want to operate it, not for a benchmark.
The three at a glance
| pgvector | Pinecone | Qdrant | |
|---|---|---|---|
| What it is | Postgres extension | Fully-managed vector DB | Open-source vector DB (self-host or cloud) |
| Ops burden | Lowest if you already run Postgres | None (SaaS) | Medium (self-host) or none (cloud) |
| Scale ceiling | Millions of vectors (with HNSW) | Very high, managed | Very high |
| Metadata filtering | Yes (SQL) | Yes | Yes (rich, fast) |
| Hybrid search | Via extensions/SQL | Yes | Yes (built-in) |
| Cost model | Your existing DB | Usage-based SaaS | Free self-host / paid cloud |
| Best when | You already run Postgres | You want zero ops at scale | You want open-source + control |
pgvector — start here if you run Postgres
pgvector adds vector similarity search to PostgreSQL. If Postgres is already in your stack, this is the pragmatic default: one fewer system to operate, your vectors sit next to your relational data (so metadata filtering is just SQL), and with HNSW indexing it comfortably handles millions of chunks. It's what I reach for first — see the Spring AI + pgvector RAG guide for a full build.
Watch-outs: at very large scale or very high query concurrency you may outgrow it, and you own the tuning (index parameters, VACUUM, etc.).
Pinecone — zero-ops managed scale
Pinecone is a fully-managed, purpose-built vector database. You don't run anything — it scales, indexes, and handles availability for you. Great when you want to not think about vector infrastructure and are comfortable with a usage-based SaaS bill.
Watch-outs: it's another vendor and cost line; your vectors live outside your primary datastore (a data-governance consideration); less control over internals.
Qdrant — open-source with control
Qdrant is an open-source vector database with strong filtering and built-in hybrid search. You can self-host (full control, no per-vector SaaS cost) or use its managed cloud. A good middle ground when you want purpose-built vector features without full vendor lock-in.
Watch-outs: self-hosting means you operate it (deployment, scaling, backups); the managed tier is a cost like any SaaS.
How to choose
- Already on Postgres, up to millions of vectors? → pgvector. Least new complexity.
- Want zero ops and will pay for it at scale? → Pinecone.
- Want open-source, control, and rich vector features? → Qdrant (self-host or cloud).
- Not sure / prototyping? → start with pgvector, migrate only if you hit a real limit. Migration is straightforward because your chunks + metadata are portable.
Whichever you pick, retrieval quality is capped by chunking, not the database. Get chunking right before blaming the store.
FAQ
Is pgvector really production-grade? Yes, for most workloads (millions of vectors, HNSW indexing). Reach for a dedicated store only when you hit its scale/concurrency limits.
Which has the best metadata filtering? All three support it well. pgvector gives you full SQL; Qdrant and Pinecone offer fast native filtering. For complex relational filters, pgvector's SQL is hard to beat.
Do I need hybrid search (keyword + vector)? Often yes — it improves recall on exact terms. Qdrant and Pinecone support it natively; with pgvector you combine vector search with Postgres full-text search.
Can I switch later? Yes. Your embeddings + metadata are portable; re-ingest into the new store. Just remember: if you also change the embedding model, you must re-embed everything.
Don't over-engineer the vector store. If you run Postgres, pgvector is the low-friction default; choose Pinecone for zero-ops managed scale, or Qdrant for open-source control. The database rarely limits answer quality — your chunking and retrieval strategy do.
More: RAG systems explained, RAG chunking strategies, and building RAG with Spring AI + pgvector.
Designing a RAG stack and want the store + retrieval choices reviewed? Let's talk.