Vector Databases 2026: Qdrant, Milvus, pgvector, Chroma Benchmark on Real Workload

Filtering breaks ANN

The main pitfall in production. Naive approach — first find nearest neighbors, then filter by tenant_id or category. If the filter cuts off 99% of the data, you’ll get almost empty result or recall will plummet. Qdrant solves this with payload indexes and filter cardinality estimation; pgvector in recent versions — iterative index scanning. This is where Chroma and naive integrations most often break.

Memory and Quantization

A million 1536-dimensional float32 vectors is about 6 GB just for raw data, plus the HNSW graph. Scalar quantization (int8) reduces this roughly 4× with minimal recall loss; binary quantization is far more aggressive but requires rescoring. If RAM budget is limited, quantization in Qdrant/Milvus is not an option — it’s a mandatory step.

Write During Read

HNSW is expensive on inserts. With a steady stream of updates (fresh documents every minute), concurrent write hurts read latency. Milvus separates this across different nodes, Qdrant uses segments, pgvector inherits Postgres MVCC with all the pros and cons of vacuum.

CODE: THE SAME TASK ON TWO ENGINES

Below — search with metadata filter, as it really looks in a RAG pipeline. First, Qdrant.

from qdrant_client import QdrantClient
from qdrant_client.models import Filter, FieldCondition, MatchValue

client = QdrantClient(url="http://localhost:6333")

# поиск ближайших с ЖЁСТКИМ фильтром по tenant и языку
hits = client.query_points(
    collection_name="docs",
    query=query_vector,          # list[float], 768 dim
    query_filter=Filter(
        must=[
            FieldCondition(key="tenant_id", match=MatchValue(value=42)),
            FieldCondition(key="lang", match=MatchValue(value="ru")),
        ]
    ),
    limit=10,
    search_params={"hnsw_ef": 128},   # управляем recall/latency
    with_payload=True,
).points

for h in hits:
    print(h.score, h.payload["title"])

The same logic on pgvector — plain SQL, the filter is just a WHERE, and proximity is computed by the <=> operator (cosine):

-- индекс создаётся один раз
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

-- для нормального recall при фильтрации
SET hnsw.ef_search = 128;
SET hnsw.iterative_scan = 'relaxed_order';

SELECT title, embedding <=> :query_vector AS distance
FROM docs
WHERE tenant_id = 42 AND lang = 'ru'
ORDER BY embedding <=> :query_vector
LIMIT 10;

The difference in philosophy is obvious right away: Qdrant is a specialized API with explicit graph control, pgvector is familiar SQL where the vector is just another column type alongside business data.

HOW TO CHOOSE FOR YOUR SCENARIO

1. Already have Postgres, volume up to a few million vectors — pgvector. Don’t proliferate infrastructure for a task that the extension solves. Joins with metadata and transactions are worth it.
2. Tens of millions of vectors, strict multi-tenant filtering, need low p99 — Qdrant. Optimal balance of speed, filtering, and operational simplicity.
3. Hundreds of millions to a billion, separate platform team — Milvus. Only if you’ve truly hit the ceiling and are ready for distributed deployment.
4. Prototype, local development, demo — Chroma. Quick start, then migrate if the project takes off.

A common mistake — pulling Milvus into an MVP ‘for growth’. In 2026, migration between engines takes a day or two (embeddings are portable), while the operational pain of premature distribution is constant. Start with the simplest option that fits your volume.

Why not just Chroma for everything?

Chroma is brilliant during development, but under high competitive QPS, large datasets, and complex filtering it lags in latency and throughput. It's a prototype tool, not a high-load production.