Choosing a vector store in 2026

Every few months someone asks me "which vector database should I use," expecting a one-word answer. There isn't one. There's a decision tree, and most people are one node deep when they need to be three.

Here's the tree I actually use, followed by the numbers that back it up.

The one-screen decision tree

1. Do you already run Postgres for this project? If yes and you're under ~5M vectors, use pgvector. Stop here. Don't add infra you don't need.
2. Are you above ~5M vectors or need sub-20ms p95 at high QPS? Go to a dedicated store.
3. Do you need managed ops (no cluster to babysit)? Pinecone.
4. Do you need the best cost-per-query at scale and don't mind running your own cluster? Qdrant.
5. Do you need hybrid search, multi-tenancy, and a GraphQL-ish query layer out of the box? Weaviate.

That's the whole tree. Everything below is why.

Cost: per 1M vectors stored, per 1M queries served

I ran the same corpus — 1536-dim OpenAI embeddings, ~4M chunks — through all four for a client project earlier this year. Rough monthly numbers, storage + query volume of 1M queries/month:

• pgvector (on a Postgres instance you're already paying for): effectively $0 incremental if you're on a box with headroom. If you're sizing a new instance for this alone, budget for the RAM to hold the HNSW index — roughly 6-8GB for 4M vectors at 1536 dims.
• Pinecone: serverless pricing lands around $70-120/month at this scale, mostly driven by read units. Predictable, but it adds up fast once query volume crosses a few million a month.
• Qdrant (self-hosted on a mid-tier VM): $40-60/month in raw compute, but that's compute you're managing — backups, upgrades, monitoring are on you.
• Weaviate (managed cloud tier): landed closest to Pinecone, $80-130/month, with the hybrid search feature bundled in rather than bolted on.

The gap that matters isn't the sticker price — it's that pgvector's cost is someone else's line item (your existing DB bill) until you cross a threshold where the index genuinely needs its own hardware. Below that threshold, the "cheapest" vector store is the one you don't provision.

Latency: p50 / p95 at scale

At 4M vectors, top-k=10, with HNSW tuned reasonably on all four:

• pgvector: p50 ~8ms, p95 ~35ms. Good enough for almost every RAG use case. The tail latency comes from autovacuum contention more often than from the index itself — watch your vacuum settings before you blame pgvector.
• Pinecone: p50 ~15ms, p95 ~40ms, but rock-solid consistency across regions. You're paying for that consistency, not raw speed.
• Qdrant: fastest of the four in my tests — p50 ~5ms, p95 ~18ms — because you can tune the HNSW parameters and hardware directly instead of going through a managed abstraction.
• Weaviate: p50 ~10ms, p95 ~30ms, comparable to pgvector but with hybrid (BM25 + dense) scoring included in that number, which is a fair trade.

None of these differences matter if your generation step takes 800ms. Retrieval latency is rarely the bottleneck in a RAG pipeline — I've seen teams spend two weeks shaving 10ms off retrieval while the LLM call sitting right after it takes three-quarters of a second. Optimize the slow part first.

Operational overhead

This is where the real cost lives, and it's the part nobody puts in a comparison table.

• Backups: pgvector rides on your existing Postgres backup strategy — free. Qdrant needs its own snapshot/restore discipline. Pinecone and Weaviate Cloud handle this for you, which is the actual value of "managed."
• Scaling: pgvector scales as far as a single (or read-replica'd) Postgres instance does — fine until you're well past 10M vectors. Qdrant and Weaviate scale horizontally with sharding, but you own the shard rebalancing. Pinecone scales invisibly, which is the point.
• Access control: if you already have row-level security in Postgres, pgvector inherits it for free — a genuinely underrated advantage for multi-tenant apps. The dedicated stores each have their own ACL model you have to learn and maintain separately from your app's auth.

Every hour spent operating infrastructure is an hour not spent on retrieval quality, which is usually the bigger lever anyway.

When pgvector is enough (most of the time)

For the large majority of RAG projects I've been on — internal tools, single-tenant SaaS products, most startups pre-Series B — pgvector is enough. You're not at the vector count or QPS where it falls over, and the operational savings compound: no new vendor contract, no new on-call surface, no new ACL model to keep in sync with your app's.

The switch to a dedicated store is a scaling decision, not a maturity decision. Don't reach for Pinecone or Qdrant because it feels more "production" — reach for it when you have a number (vectors, QPS, or p95 target) that pgvector actually can't hit. Until then, the boring choice is the correct one.