Choosing a Vector Database in 2026: When to Use pgvector, Qdrant or Milvus

TL;DR — Choosing a vector database in 2026 is no longer "which one is coolest" — it's "which one ships to production with the least friction for my workload." My short answer: if you're already on PostgreSQL, pgvector (or Supabase) is the fastest path to production and handles up to ~10M vectors comfortably. If lowest latency is the priority, Qdrant is consistently the fastest in reported benchmarks (~4ms p50). Don't touch Milvus unless you genuinely need billion-scale distributed workloads and have a dedicated ops team. Want hybrid search and GraphQL ergonomics? Look at Weaviate. All numbers below are 2026 reported benchmarks — re-verify on your own data.

Roughly half the teams I consult with come to me with the same question: "Which vector database should we set up for our RAG system?" And almost every time, the question itself is slightly wrong. The real issue isn't "which database" — it's "which constraint is actually squeezing me."

There are three axes, in constant tension:

• Latency: the p50 and especially p99 of your nearest-neighbor lookup directly shapes whether users feel the system is snappy or laggy.
• Scale: 100K documents, 10M, or 2 billion vectors? This number ruthlessly narrows your options.
• Ops burden: who keeps this thing alive? A separate cluster, or an extension on the Postgres you already run? This determines your on-call nights more than your monthly bill.

A field observation: most teams overweight latency and scale and underweight ops burden. I've seen teams install Milvus "so we can scale to a billion vectors" who actually have 400K documents and wake up at 3am to keep that distributed cluster healthy. That's the classic over-engineering trap.

Read this as a compass, not scripture. Numbers are 2026 reported benchmarks — re-verify on your own workload.

Database	Latency (reported)	Scale sweet spot	Strengths	When to use
pgvector	Tied to Postgres; good to ~10M	Up to ~10M vectors	Already in Postgres; zero new infra; SQL joins	Team already on PostgreSQL; fastest path to prod
Qdrant	~4ms p50, ~25ms p99 (some report p99 <15ms)	Mid-to-large; tens of millions	Rust + custom HNSW; consistently lowest latency	Latency is the top priority; managed or self-host
Milvus	~6ms p50	Billion-scale, distributed	GPU acceleration; most index algorithms	Genuine billion-scale + dedicated ops team
Weaviate	Competitive	Mid-to-large	Hybrid search, GraphQL ergonomics	Hybrid search & API ergonomics are the priority

The most critical column for me is the one most people read last: "When to use." Latency differences are milliseconds and most users won't feel them. But the operational model difference defines your team's weekly reality.

If you open a ticket asking "which one should I start with," my answer is probably pgvector. Not romantic — pragmatic: most teams already run PostgreSQL.

Your app data is already in Postgres — users, orders, document metadata. pgvector arrives as an extension and puts your embeddings in the same database, same transaction boundaries, same backup and replication pipeline. No new service, no new cluster, no new query language. CREATE EXTENSION vector; and carry on.

You don't fully appreciate how big this is until you're in production. When you want to combine vector search with relational filters — "find nearest neighbors among documents this user can access, updated in the last 30 days" — in pgvector that's a single SQL query. In a separate vector DB it means wiring two systems together, juggling IDs, and fighting consistency.

Where does pgvector hit a wall? Per reported figures, it works well up to about 10 million vectors. Beyond that, especially under high-recall load, plain pgvector strains. Here's an important nuance: pgvectorscale, the tuned extension. At 50M vectors and 99% recall, Qdrant reaches ~41.47 QPS while pgvectorscale reaches ~471 QPS — an order-of-magnitude difference.

I read that twice the first time. Context matters: it's a comparison with tuned pgvectorscale in a specific setup. The lesson isn't "pgvector always wins"; it's that the Postgres ecosystem pushes the point where you must leave it much further out than most teams assume. Before assuming you're stuck at 10M and launching a huge migration — did you try pgvectorscale?

A Turkey note: many organizations already run a managed PostgreSQL (in their own data center or a local cloud). Putting vector search there is also the least-friction path for KVKK and data residency, because you move no data to a new system.

"

Field rule: if you're building your first RAG system and already have Postgres, start with pgvector. Standing up a distributed system on day 1 out of fear it "won't scale" is solving a problem you don't have.

If pgvector is "start simple," Qdrant is the answer for "when it has to be fast." In reported 2026 benchmarks, among purpose-built vector databases, the lowest p50 latency (~4ms) belongs to Qdrant. On p99, some benchmarks report ~25ms, others under 15ms. And it's no fluke — Qdrant consistently comes out fastest.

Under that speed is an engineering choice: Qdrant is written in Rust with a custom HNSW implementation. Rust means predictable low latency without garbage-collector pauses — critical for keeping p99 flat. The custom HNSW lets them shape filtering and index behavior to their needs rather than being bound to a general-purpose library.

What I like in practice is that Qdrant offers both managed (Qdrant Cloud) and self-hosted options. That duo is especially valuable for my clients in Turkey: prototype fast on managed, then self-host the same engine when data sensitivity demands it. Because the engine is identical, the migration doesn't hurt like switching products would.

When Qdrant? When you've outgrown pgvector's comfort zone (tens of millions of vectors), latency is the top UX priority, and you're ready to run a separate vector service. For a real-time recommender or a search-as-you-type interface, that ~4ms p50 is genuinely felt.

A caution: don't fetishize Qdrant either. If you have 200K documents and a few queries per second, users will never notice the latency edge — but you'll feel the burden of running a separate service every day. Speed is a feature when you actually need speed; otherwise it's unsolved ops burden.

I change my tone for Milvus, because for most teams it's a trap. Milvus is superb engineering — and a superb headache in the wrong hands.

The numbers: ~6ms p50, GPU acceleration, and the most index algorithms for tuning. Its true strength is large-scale distributed deployments — billion-scale workloads. If you genuinely have billions of vectors to scale horizontally, Milvus's architecture is built for it.

But the key point: Milvus's power is also its operational cost. A distributed Milvus deployment is a system of moving parts — coordinators, worker nodes, object storage, message queue. Keeping that healthy in production demands expertise incomparable to maintaining a Postgres extension. So my advice is blunt: avoid Milvus unless you genuinely need billion-scale and have a dedicated ops team.

A field story: a team started on Milvus "to be ready when we grow." Six months in they had 900K vectors — laughably small for Milvus — but operating the cluster ate a large share of their two most experienced engineers' time. We moved them to pgvector; latency was fine and those engineers finally returned to the actual product. Milvus wasn't bad; it was the right tool for the wrong problem.

Weaviate earns its table spot because it genuinely shines for a specific need: hybrid search (vector + keyword together) and GraphQL API ergonomics. If your search must be enriched by exact keyword matching, not pure semantic similarity — common in legal, medical, or product-catalog search — Weaviate blends these elegantly. It's not my default, but for a team that says "hybrid search is vital," I'll always tell them to put it on the evaluation list.

Now the most important heading, and I'll say it firmly because I see the same mistake repeatedly: start with what you have.

The number-one mistake in vector database selection is engineering for a scale you don't yet have. "What if we go viral?" "What if we hit a billion documents?" These sound legitimate, but in practice you're slowing down today's velocity to solve an unborn problem.

The truth: most RAG and semantic search projects stay under 10 million vectors for their entire life. That means you're in pgvector's comfort zone. There, standing up a separate vector DB saves you maybe a few milliseconds but costs ops burden, a second data system, sync headaches, and a learning curve. For most teams, that's a losing trade.

"

Field rule: "we'll need it" is not an engineering justification. "At our current load we can't hit this metric" is. Don't decide based on the former until you see the latter.

Whichever database you pick, you'll likely use an HNSW index. The core truth: there's a constant tradeoff between recall and latency, and you tune it.

Three parameters shape your fate:

• m — connections per node. Higher m means a richer graph, better recall, more memory, slower build.
• ef_construction — search width at build time. Higher means a higher-quality index but longer build.
• ef_search — search width at query time. This is where you tune the latency/recall tradeoff live. Higher ef_search means better recall but higher latency.

In practice I set a recall target (say 95%), then tune ef_search to the lowest value that hits it. Because 99% recall sounds better than 95%, but if it doubles latency and users don't notice the difference, you're paying for recall that goes to waste. The "right" values depend on your data distribution, embedding dimension, and query patterns — copy blog values as a starting point, but find the final values by measuring on your data.

A common mistake: choosing the vector database independently of the embedding model. They're a whole. Vector quality comes from your embedding model; the database just finds them fast. Feed it garbage vectors and the world's fastest database finds you garbage neighbors — very quickly.

Decide together: dimensionality (384 vs 1536 vs 3072 — higher means more memory and slower search; Matryoshka-style truncation can help), distance metric (cosine, dot product, or L2 must match how your model was trained — a mismatch is a silent recall killer), and normalization (some models emit normalized vectors, some don't; the wrong assumption corrupts your similarity scores).

I've given numbers throughout, but my most important advice: don't trust any of them because I said so. Measure on your own data.

Benchmarks run on standard datasets, standard setups, often ideal conditions. Your data has a different distribution, your queries a different pattern, your infra a different config. "Qdrant ~4ms" is a starting hypothesis, not a production decision.

A simple protocol:

1. Build a ground-truth set. Take 100-500 representative queries from your own data and compute the correct results (via brute-force exact search).
2. Measure recall@k for each database and parameter combination.
3. Measure latency under realistic load — p50, p95, p99 under concurrency, not single queries.
4. Measure resources — memory, CPU, disk. That ~4ms may come with 64GB RAM; is it in your budget?
5. Put the tradeoff in a table. Let recall, latency, and cost side by side make the call — not a gut feeling.

Working with clients in Turkey, there's a non-technical but decisive axis: where will the data live?

KVKK and many sector regulations (banking, health, public sector) require data to stay within certain boundaries, sometimes in-country. What's in your RAG system? Usually an organization's most sensitive internal documents. Their embeddings are sensitive data too — a lot about the original text can leak from an embedding. Don't dismiss them as "just numbers."

Here self-hosting isn't a luxury; it's often a requirement. The good news: all three tools here (pgvector, Qdrant, Milvus) can run on your own infra. pgvector is already in your Postgres — no extra system, inside your existing compliance envelope. Qdrant self-hosts cleanly, with the same engine as managed. Milvus self-hosts too, but the ops burden above still applies.

Add a "data residency and compliance" axis explicitly next to your technical axes. For some teams, that axis removes a technically "better" managed cloud from the table — and that's entirely correct. Compliance is a constraint from the start, not a feature added later.

Ask these in order for your next selection.

1. Already on PostgreSQL? If yes and under ~10M vectors (or beyond, with pgvectorscale): start with pgvector. The decision likely ends here.
2. Is latency your top priority and have you outgrown pgvector's zone? If yes: Qdrant.
3. Genuinely billion-scale AND a dedicated ops team? Both yes: Milvus. Otherwise — especially without the second — avoid it.
4. Is hybrid search vital? If yes: put Weaviate on your evaluation list.
5. Is data residency / KVKK a constraint? If yes: filter to self-hosted options — this may remove managed-only services, correctly.
6. Did you measure on YOUR data? If not, you haven't decided — you have a hypothesis.

The spirit of this framework: start with the most boring solution, stay there until measurement forces you to move, and move on data when it does. Vector database selection isn't an irreversible marriage; put embedding generation and storage behind the right abstractions and you can switch when tomorrow's needs change. The biggest risk isn't picking the wrong database — it's slowing yourself down today for a problem you don't yet have.