Vector Database for RAG: pgvector vs Pinecone vs Qdrant (2026)

Which vector database should you pick for RAG?

A vector database stores your embeddings and returns the nearest matches at query time. Pick pgvector if you already run Postgres and want SQL joins in one system; pick Pinecone if you want a zero-operation managed service and accept a SaaS bill; pick Qdrant if you want open-source, self-hostable search with strong metadata filtering and hybrid retrieval. At around 1M vectors, recall is basically a tie — so choose on operations and fit, not on a benchmark row.

Here’s the part that surprises people: at that scale, every mainstream engine hits roughly 95%+ recall with default HNSW settings. The real differences show up at 10-100M vectors, in operational burden, in metadata filtering, and in hybrid search. This is the “which store” companion to the build-a-RAG-system-with-Claude tutorial. If you’re still deciding whether RAG is even the right tool versus fine-tuning, start there first, then come back to pick a store.

What a vector database actually does

A vector database stores two things per record: an embedding (a list of floats — with Voyage’s voyage-4, that’s a 1024-dimensional vector) and its metadata (tenant ID, source URL, date, the original text). When a query comes in, you embed the query with the same model, then the database runs an approximate nearest-neighbor (ANN) search — almost always backed by an HNSW index — to return the top-k most similar vectors fast. That’s the whole job: store, then retrieve the closest matches.

Two things matter here. First, ANN is approximate on purpose — trading a sliver of recall for a massive speedup, which is why you tune it rather than expecting exact results. Second, the vector database is decoupled from the embedding model. The same voyage-4 vectors work in pgvector, Pinecone, or Qdrant unchanged. You’re choosing a retrieval and storage layer, not locking in an embedding provider.

pgvector: the Postgres extension

pgvector is not a separate database — it’s an open-source Postgres extension. You install it, and Postgres gains a vector column type plus ANN indexes (HNSW and IVFFlat). Distance operators come as SQL: <-> for L2, <=> for cosine, <#> for inner product. Because Voyage embeddings are normalized, inner product and cosine rank identically, so pick whichever reads cleaner.

The whole pitch is one database. Your relational rows and your vectors live together — real SQL joins, transactions, and your existing backups and monitoring all apply. Filtering by tenant or date is just a WHERE clause on the same table.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunks (
  id         bigserial PRIMARY KEY,
  tenant_id  text NOT NULL,
  source     text,
  content    text NOT NULL,
  embedding  vector(1024)          -- voyage-4 dimensionality
);

-- HNSW index for cosine distance
CREATE INDEX ON chunks
  USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

-- top-5 nearest chunks for one tenant, filtered in the same query
SELECT id, content
FROM chunks
WHERE tenant_id = 'acme'
ORDER BY embedding <=> $1      -- $1 = the query embedding
LIMIT 5;

It’s production-grade in 2026 — managed Postgres platforms like Supabase and Neon ship it. The trade-off: you tune it (m, ef_construction, ef_search) and you scale Postgres yourself. At 100M+ vectors, that tuning gets real compared to a purpose-built engine. If your scale sits in the range a solid Postgres already handles, pgvector is usually the lowest-total-complexity option.

Pinecone: fully-managed serverless

Pinecone is a fully-managed, serverless vector database — SaaS, not open source. The appeal is zero operations: no servers to run, no index nodes to size, it autoscales, and you pay for usage. Its serverless architecture (GA 2024) replaced the older per-pod cost model, so you’re no longer provisioning capacity you might not use.

The strength is obvious: production RAG without operating any infrastructure, with sensible scaling defaults. If your team can’t (or shouldn’t) dedicate someone to running a vector store, this takes it off your plate. The trade-offs are equally clear — it’s a proprietary vendor, your data lives in Pinecone’s cloud, and the bill is usage-based. If your data has residency constraints or you want to avoid a new external dependency, that matters. If you’d rather never think about an index again, that’s exactly what you’re paying for.

Qdrant: open-source Rust

Qdrant is an open-source, Rust-based vector database. It’s built for strong single-node performance, rich metadata filtering, quantization to shrink memory, and hybrid search — combining dense (semantic) and sparse (keyword) vectors so exact-term matches don’t get lost in semantic soup.

You can run it two ways: self-hosted via Docker or a binary, or Qdrant Cloud (managed, with a free tier). That makes it the natural pick when you want a Pinecone-like managed option or full self-hosting, and you specifically don’t want a Postgres dependency.

docker run -p 6333:6333 qdrant/qdrant

The strength: an open-source, self-hostable alternative to Pinecone with excellent filtering and hybrid search out of the box. The trade-off: self-hosting Qdrant is one more service to operate, monitor, and back up — unless you offload that to Qdrant Cloud and return to the SaaS-bill model.

Honorable mentions: Chroma and Weaviate

Two more worth knowing, without the deep dive. Chroma has the best developer experience for prototyping — Python-native, in-memory by default, a one-line install. Its production story has improved, but it’s still lighter than Qdrant or Weaviate, so it shines most in a local notebook while you’re validating retrieval quality. Weaviate is notable for strong built-in hybrid search; if dense plus keyword out of the box is your top requirement, it belongs on your shortlist next to Qdrant.

Rule of thumb: prototype in Chroma, then graduate to pgvector, Pinecone, or Qdrant when you need multi-tenant filtering, scale, and real operations.

How to choose by scenario

Map your actual constraint to a store rather than chasing a benchmark. Every mainstream engine supports metadata filtering (tenant, date, source) alongside vector search — that’s non-negotiable for multi-tenant RAG, and they all do it — so filtering capability isn’t the tiebreaker; where you want to run the thing usually is.

Concretely: if you already run Postgres and value one system with SQL filters, pgvector removes an entire moving part. If you’re a small team that wants to ship production RAG and never operate an index, Pinecone is the shortest path. If you want open-source performance with strong filtering and hybrid search and no Postgres dependency, Qdrant fits — self-hosted or on their Cloud. And if you’re still validating whether retrieval even works, prototype in Chroma before committing.

Cost and ops reality (and why recall isn’t the deciding factor)

The honest framing is that recall is a solved problem at the scale most teams operate. All the mainstream engines reach ~95%+ recall at ~1M vectors with default HNSW. Differences emerge at 10-100M vectors, in how much ops burden you’re willing to carry, in the quality of metadata filtering, and in hybrid search. So don’t pick on a benchmark table — pick on the cost model and who operates it.

Self-hosted stores (pgvector, self-hosted Qdrant) run on infrastructure you already pay for — the cost is your team’s time to tune and operate. Managed stores (Pinecone, Qdrant Cloud) convert that into a usage-based SaaS bill. Neither is universally cheaper; it depends on your team’s size and where your time is better spent. I won’t quote latency or price tables — vendor pricing moves and depends on your load, so verify against the official docs: pgvector on GitHub, pinecone.io, and qdrant.tech.

Where the vector DB plugs into your RAG pipeline

Whichever store you pick, it slots into the same spot: after chunking and embedding, before generation. Before you embed anything, redact sensitive PII like CURP, RFC, and CLABE so it never lands in your index. For the generation step, wire the retrieved chunks into the Claude Messages API and ground the model so it answers only from retrieved context instead of hallucinating. Browse the rest of the AI agents hub for the surrounding pieces.

The store is important, but it’s one hop. Pick the one that fits how your team wants to operate, ship it, and spend your remaining energy on chunking, reranking, and grounding — that’s where retrieval quality is actually won.