Vector Database Selection Guide: Qdrant vs Milvus vs pgvector — Architecture & Scenario Decisions (2026)

Bottom line first: there is no best vector database, only the one that best fits your scenario

In the RAG knowledge base pipeline, the vector database is the component most often underestimated and most often chosen wrong. Pick too light (pgvector cannot handle billions) and you will have to rebuild; pick too heavy (distributed Milvus from day one) and ops costs eat the entire project budget.

This guide breaks down four mainstream vector databases by architecture, gives a five-dimension decision matrix, and covers three high-frequency pitfalls we have seen in production.

---

1. Architecture differences across four vector databases

Qdrant — fastest onboarding, simplest ops

Written in Rust, starts in minutes with a single Docker container. Its standout strength is filter performance: it supports payload-based pre-filtering at the index level rather than post-filtering retrieved results. Ideal for scenarios with heavy metadata filtering (by customer, date, permissions).

Feature	Qdrant
Language	Rust
Deployment	Standalone Docker / K8s / Cloud
Index	HNSW (primary), quantization support
Filtering	Built-in payload index — excellent filter performance
Consistency	Strong / tunable
Scale	Millions on single node, billions with K8s

Milvus — distributed, billion-scale

Written in Go/Java with a layered architecture (Query Node / Index Node / Data Node), K8s-native. Its strength is scale — supports tens of billions of vectors with multiple index types (HNSW, IVF_FLAT, IVF_PQ, DiskANN) via the Knowhere engine. The trade-off is ops complexity — many components, many tuning parameters. Overkill for small-scale scenarios.

Feature	Milvus
Language	Go / Java
Deployment	K8s-native (recommended) / Docker Compose
Index	HNSW / IVF / DiskANN / multiple quantizations
Filtering	Scalar inverted index, moderate performance
Consistency	Tunable (strong / bounded / session / eventual)
Scale	Billions+, distributed by nature

pgvector — zero new components, reuse PostgreSQL

A PostgreSQL extension that embeds vector search directly into your existing database. Its strength is zero additional ops — if you already run PostgreSQL, just enable the extension. Suitable for small-to-medium datasets (under 10 million vectors), existing PG infrastructure, and scenarios requiring real-time consistency and transaction support.

Feature	pgvector
Language	C (PG extension)
Deployment	PostgreSQL plugin
Index	IVFFlat / HNSW (pgvector 0.7+)
Filtering	Via WHERE clause — post-filtering
Consistency	PostgreSQL transaction guarantees
Scale	Under 10M vectors, with existing PG

Elasticsearch — full-text + vector in one

If your search infrastructure already runs on Elasticsearch, ES 8.x vector search (kNN search + HNSW index) lets you handle hybrid search in one system, avoiding an extra component.

Feature	Elasticsearch
Language	Java
Deployment	Standalone / cluster, with existing ES
Index	HNSW (dense_vector field)
Filtering	ES query DSL — flexible but complex
Consistency	Near-real-time (NRT)
Scale	Existing ES scenarios, billion-scale with cluster

---

2. Decision matrix: five dimensions

Dimension	Qdrant	Milvus	pgvector	Elasticsearch
① Under 10M vectors	✅ Recommended	❌ Overkill	✅ Recommended	✅ Acceptable
② Billions of vectors	❌ Needs K8s	✅ Recommended	❌	❌ Needs cluster
③ Existing PostgreSQL	—	—	✅ Recommended	—
④ Existing ES	—	—	—	✅ Recommended
⑤ Strong consistency / transactions	❌ Tunable	❌ Tunable	✅ Strong	❌ NRT
⑥ Limited ops, want lightweight	✅ Recommended	❌ Many components	✅ Recommended	❌ Needs ES ops
⑦ Heavy metadata filtering	✅ Recommended	❌ Moderate	❌ Post-filter	❌ Complex
⑧ Large-scale distributed	❌ Needs K8s	✅ Recommended	❌ PG extension	❌ Needs cluster

Our default path: Prototype with pgvector (zero-cost validation) → migrate to Qdrant (single-node enough) or Milvus (billion-scale distributed) for production. Only consider ES when you already run it.

---

3. Three high-frequency pitfalls

Pitfall 1: Wrong index selection

The practical difference between HNSW and IVF is severely underestimated. Picking the wrong one means either queries are too slow or the index is too large for memory.

Scenario	Recommended index	Why
Online retrieval, write-once-read-many	HNSW	Fast queries (milliseconds), build time is acceptable
Batch write, offline retrieval	IVF	Fast build, slower queries (tunable via nprobe)
Resource-constrained (low memory)	IVF + PQ	Quantization compresses vectors 4-8×
Massive scale (billions+)	DiskANN	Disk-based index, only the graph in memory

Pitfall 2: Ignoring metadata filter performance

Vector search is fundamentally “find similar first, then filter”. If the filter is strict (e.g. “only 2026 data + customer A + type B”), the traditional approach is vector search Top-K first, then post-filter — if the filter eliminates most results, the Top-K may contain zero valid results, and recall drops to zero.

Qdrant’s payload index avoids this by filtering at the index level. If you use pgvector or ES with post-filtering, set Top-K high enough (10× the expected return count) or you risk empty result sets after filtering.

Pitfall 3: Wrong embedding dimensionality

768 dimensions is the current sweet spot (bge-m3, text-embedding-3-small, and most mainstream models). Going above 1024 (e.g. text-embedding-3-large at 3072 dimensions) brings marginal recall gains of 2-5% but doubles memory and query time. For small-scale scenarios (under 1M vectors), 384 dimensions (e.g. all-MiniLM-L6-v2) is sufficient — memory is half of 768-dim.

---

4. After selection: evaluation matters

Choosing the right vector database does not guarantee good retrieval quality. Selection only solves “stores well and retrieves fast”. Retrieval quality depends on the embedding model, chunking strategy, metadata design, and hybrid search configuration — all covered in our RAG guide.

Further reading:

• AI Agent Memory System Design — the vector DB is the storage layer of long-term memory: what to store, how to retrieve, how to forget
• Enterprise RAG Knowledge Base Guide — companion piece: chunking, hybrid search, evaluation loop
• AI Customer Service in Practice — knowledge-base engineering for support scenarios: intention routing, hybrid retrieval, human handoff
• How to Evaluate an AI Project After Launch — Recall@K, MRR metrics, and eval set building
• AI Observability Design — monitoring retrieval quality in production
• On-prem LLM Sizing Calculator — precise hardware budget for self-hosted inference

Vector database selection is just one link in the RAG pipeline, but choosing wrong is expensive — not because of performance, but because discovering the mistake after launch costs far more than spending a few extra days on evaluation during selection. When we deliver RAG knowledge bases and AI engineering augmentation, the selection-stage evaluation process is a standard deliverable: we recommend based on data volume, scenario characteristics, and ops capability, and validate the choice during the PoC phase.

If you are evaluating a vector database for your RAG knowledge base, bring us the scenario. We provide AI engineering augmentation and decision-layer services: RAG knowledge bases, agent orchestration, on-prem inference deployment, plus technology roadmap evaluation and selection review — no promises to do everything, only what we are good at.