Vector Databases in 2026: pgvector vs Pinecone vs Qdrant vs Weaviate vs Milvus

A vector database is a search index, not a source of truth. The interesting decisions are: which index type, how to combine with lexical search, how to filter by metadata efficiently, how to re-embed without downtime, and how to pay for the storage. This article walks the trade-offs I've hit shipping RAG across 20+ projects.

It pairs with RAG that actually works (which explains why hybrid + rerank beats pure ANN), Postgres for product engineers (the base you're extending with pgvector), evaluating LLMs and classical ML (how to know if your retriever improved), and observability for AI systems (what to trace in retrieval).

Every column below reflects behavior at 1M vectors, 1024-dim embeddings, and hybrid queries with metadata filters, on comparable hardware. Numbers rounded from my own load tests — treat as within ±20%.

A quick heuristic: if your total corpus fits in RAM on a $200/mo VM, pgvector wins on total cost of ownership. Cross that line and Qdrant is my next default.

The store name matters less than the index inside it. Every serious ANN store exposes some subset of:

Almost all production RAG in 2026 is HNSW with efSearch tuned per query — that gets you 95%+ recall at 20ms. Move to IVF-PQ or DiskANN only when the RAM bill actually hurts.

Once you cross ~1M docs, pure ANN speed matters less than how well the store combines a metadata filter with the vector search. Three strategies:

1. Post-filter — run ANN, then drop rows that fail the filter. Fast if filter is loose, disastrous if filter is tight (you retrieve 10k to keep 5).
2. Pre-filter — apply the filter first, then ANN only over the candidate set. Requires a payload index. Qdrant and Weaviate excel here.
3. Query planner — decide per query based on estimated selectivity. pgvector gets this for free from Postgres' planner.

If your app filters by tenant, language, doc-type, and date on every query — and most do — pre-filter or planner-based stores will beat ANN-only stores by 3–10× at p95.

Pure dense search misses exact identifiers (SKUs, error codes, names) and pure BM25 misses paraphrases. Reciprocal Rank Fusion (RRF) of the two top-N lists is the boring, dominant baseline in 2026.

def rrf(bm25_hits, dense_hits, k=60, top=20):
    scores = {}
    for rank, doc_id in enumerate(bm25_hits):
        scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank)
    for rank, doc_id in enumerate(dense_hits):
        scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank)
    return sorted(scores, key=scores.get, reverse=True)[:top]

pgvector implements this in SQL; Qdrant and Weaviate expose it as a single query. Full pattern with reranking in RAG that actually works.

pgvector — the boring choice that ships

You already run Postgres. You want joins, transactions, RLS on your vectors, and a single backup story. This is the answer 60% of the time.

Qdrant — my default for standalone

Rust core, generous free self-hosted, best-in-class filter-then-search. Payload indexing means filter queries stay fast even at 100M vectors. Snapshots and rolling upgrades are painless.

Pinecone — pay to not think about ops

Fastest to production. Serverless tier auto-scales. Pricing gets loud past 10M vectors — do the annual math before committing. Weakness: metadata filtering is thinner than Qdrant/Weaviate.

Weaviate — for schema-first teams

If your RAG has real entities (Product, Author, Article) with typed relationships, Weaviate's schema shines. Built-in modules for embeddings, reranking, and multi-tenancy at scale.

Milvus — the billion-scale monster

Only pick this if you actually need it. The ops complexity is real — separate coord, query, data, index nodes; you'll want a dedicated infra engineer. See parallels in self-hosting n8n on Kubernetes for the operational overhead.

1. Are you already on Postgres and under 5M vectors? → pgvector. Stop here.
2. Do you want zero ops and have budget? → Pinecone.
3. Do you need rich metadata filters at 10M+ scale? → Qdrant.
4. Do you have complex typed entities and want multi-tenancy first-class? → Weaviate.
5. Do you have >500M vectors and a dedicated ops team? → Milvus.

SaaS with per-tenant corpora needs a serious answer for isolation. Four common patterns:

• Row-level filter — one collection, tenant_id on every vector, filter in query. Simple, cheap, risky if the filter is ever forgotten.
• Namespace/collection per tenant — hard isolation, but ops burden grows linearly (backups, index rebuilds).
• RLS (pgvector) — Postgres enforces at the row level. Combine with the pattern in Postgres for product engineers. This is my default for SaaS.
• Sharding by tenant — for whales. Route large tenants to dedicated shards, keep small tenants pooled.

The single biggest hidden cost: re-embedding when you upgrade the model. For 100M vectors at $0.02/1M input tokens with 300-token chunks, a re-embed is ~$600 in API cost alone, plus rewrite time.

The safe pattern is dual-write with lazy read-side migration:

1. Add a new column/collection for the new embedding.
2. Backfill in batches with a rate limit; monitor cost live.
3. Dual-write: every new document embeds into both old and new.
4. Behind a feature flag, route reads to the new index for a percent of traffic.
5. Once quality holds on the eval set, cut fully and drop the old column.

pgvector supports this trivially (just add a column). Pinecone requires a new index. Qdrant/Weaviate/Milvus support named vector fields on the same collection — plan for that from day one.

Also budget for network egress if you call a hosted embedder from a different region than your vector store — this quietly adds hundreds/month at scale. Route the whole read/write path in one cloud region if you can.

For attributing this to the right feature/customer, wire it into your LLM cost dashboard alongside completion costs.

1. Load 1M representative vectors with real metadata distribution.
2. Run a 1,000-query eval set for recall@10 and NDCG@10.
3. Load-test 100 concurrent queries with realistic filters; record p50/p95/p99.
4. Simulate a full re-embed and time it end-to-end.
5. Kill a node mid-query and observe recovery.

Do this before you sign a contract or commit to a self-hosted stack. Two days of load testing has saved every client I've done it for from a very expensive rewrite six months later.

Great for prototyping and local-first apps. I don't yet run them as the primary store in production — the ecosystem around backups, monitoring, replication, and multi-tenant isolation is still thinner than the five in this guide. Revisit yearly; the gap is closing.