KI & LLM 8 Min Lesezeit

Vektordatenbanken im Vergleich 2026 – Qdrant, Milvus, Chroma

Warum Vektordatenbanken 2026 zum Standard-Stack gehören

Noch 2023 bestand ein typischer RAG-Stack aus FAISS-Index plus Pickle-Datei. Das funktioniert für ein Notebook, aber nicht für einen Dienst, der 24/7 läuft, Metadaten filtert, Nutzer isoliert und inkrementell neue Dokumente aufnimmt. Genau diese Lücke füllen dedizierte Vektordatenbanken: Sie kombinieren einen ANN-Index (Approximate Nearest Neighbor) mit Persistenz, CRUD-Operationen, Metadaten-Filtern, Replikation und Monitoring.

Der Treiber ist die Embedding-Dimension. Kleine Modelle wie all-MiniLM-L6-v2 liefern 384 Dimensionen, BGE-base und e5-base liegen bei 768, OpenAI text-embedding-3-small bei 1536, text-embedding-3-large bei 3072. Jede Dimension kostet 4 Byte pro Vektor in float32 – bei 10 Millionen Chunks sind das schnell 60 GB RAM, bevor der Index überhaupt gebaut ist.

Dazu kommt Filtering: „Finde die 5 ähnlichsten Absätze, aber nur aus Dokumenten von Mandant 42, die nach 2025 veröffentlicht wurden." Ohne Payload-Index wird daraus ein Full-Scan über alle Vektoren. Qdrant, Milvus und Chroma lösen das unterschiedlich gut – und genau darin unterscheiden sie sich 2026 am stärksten.

Die drei Kandidaten im Kurzprofil

Merkmal	Qdrant	Milvus	Chroma
Kern in	Rust	Go + C++	Rust (ab 1.0)
Lizenz	Apache 2.0	Apache 2.0	Apache 2.0
Deployment	Single Binary, Docker, Distributed	Standalone, Distributed (K8s)	Embedded, Single-Node Server
Praktische Obergrenze	Milliarden Vektoren	>10 Milliarden Vektoren	~5–10 Mio. Vektoren
Filtering	Filterable HNSW, Payload-Index	Scalar Filtering mit Expressions	where-Filter, einfacher
GPU-Index	Nein	Ja (CAGRA, GPU_IVF)	Nein
Hybrid Search	Dense + Sparse (BM25)	Dense + Sparse, RRF	Eingeschränkt
Managed Cloud	Qdrant Cloud	Zilliz Cloud	Chroma Cloud

Die Kurzfassung: Chroma ist der schnellste Weg zum funktionierenden Prototyp, Qdrant ist der Allrounder für Produktions-Workloads bis in den zweistelligen Millionenbereich, Milvus ist die Wahl, wenn Sharding, GPU-Beschleunigung und Mandantentrennung auf Kubernetes gefragt sind.

Qdrant: Rust-Performance mit starker Filterung

Qdrant setzt auf einen in Rust geschriebenen HNSW-Index mit einem entscheidenden Detail: dem Filterable HNSW. Filter werden nicht nach der Suche angewendet, sondern während der Graph-Traversierung berücksichtigt. Das verhindert den klassischen Recall-Einbruch, wenn ein Filter 95 % des Korpus ausschließt.

Für den Speicherbedarf gibt es drei Quantisierungsstufen: Scalar Quantization (int8) reduziert auf ein Viertel, Product Quantization auf bis zu 1/64, Binary Quantization auf 1/32 der Originalgröße. Bei Binary Quantization wird mit Oversampling und Rescoring nachgearbeitet – der Recall bleibt typischerweise über 0,95.

from qdrant_client import QdrantClient
from qdrant_client.models import (
    Distance, VectorParams, ScalarQuantization,
    ScalarQuantizationConfig, ScalarType, PointStruct
)

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

client.create_collection(
    collection_name="handbuch",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
    quantization_config=ScalarQuantization(
        scalar=ScalarQuantizationConfig(
            type=ScalarType.INT8, quantile=0.99, always_ram=True
        )
    ),
)

client.upsert(
    collection_name="handbuch",
    points=[PointStruct(id=1, vector=[0.01]*1536,
                        payload={"mandant": 42, "jahr": 2026})],
)

Der REST-Port ist 6333, gRPC läuft auf 6334, das Web-UI unter http://localhost:6333/dashboard. Metriken für Prometheus liefert derselbe Port unter /metrics. Qdrant lässt sich zusätzlich als lokaler In-Memory-Client ohne Server betreiben – praktisch für Tests, aber ohne Persistenz.

Milvus: Verteiltes System für Milliarden Vektoren

Milvus ist keine Datenbank im klassischen Sinn, sondern eine verteilte Architektur aus mehreren Rollen: Proxy, Query Nodes, Data Nodes, Index Nodes sowie ein Koordinator-Layer (in 2.5 zu MixCoord zusammengeführt). Als externe Abhängigkeiten laufen etcd für Metadaten, MinIO oder S3 für Objektspeicher und Pulsar oder Kafka als Log Broker.

Diese Komplexität ist der Preis für echte horizontale Skalierung. Dafür bekommt man Index-Typen, die andere nicht bieten: DiskANN für Vektoren, die größer als der RAM sind, GPU_CAGRA für beschleunigte Suche auf A100/H100, IVF_PQ für komprimierte Milliarden-Korpora. Milvus unterstützt vier Konsistenzlevel von Strong bis Eventually – ein bewusster Trade-off zwischen Latenz und Aktualität.

Für kleine Projekte gibt es Milvus Lite: eine eingebettete Variante, die per pip install pymilvus kommt und bis etwa eine Million Vektoren mitspielt. Der Wechsel zum Server-Deployment ist ein URL-Wechsel im Client.

wget https://github.com/milvus-io/milvus/releases/download/v2.5.4/milvus-standalone-docker-compose.yml -O docker-compose.yml
docker compose up -d
# Ports: 19530 (gRPC), 9091 (Metrics/Health)

Chroma: Minimaler Einstieg für Prototypen

Chroma war lange die Python-first-Lösung mit SQLite und hnswlib im Hintergrund. Mit Chroma 1.0 wurde der Kern in Rust neu geschrieben, was laut Projektangaben rund 4× schnellere Writes und eine deutlich stabilere Nebenläufigkeit bringt. Die API blieb dabei weitgehend kompatibel.

Der große Vorteil ist die Reibung: fünf Zeilen Code, kein Server, keine Konfiguration. Der Nachteil ist genauso klar: Chroma skaliert vertikal, nicht horizontal. Es gibt kein Sharding, keine Replikation und kein GPU-Backend. Für Notebooks, Demos und interne Tools mit unter einer Million Vektoren ist das völlig ausreichend.

import chromadb

client = chromadb.PersistentClient(path="./chroma_db")
col = client.get_or_create_collection(
    name="handbuch", metadata={"hnsw:space": "cosine"}
)
col.add(ids=["d1"], documents=["Wie skaliere ich Qdrant?"],
        metadatas=[{"quelle": "handbuch.pdf", "jahr": 2026}])
res = col.query(query_texts=["Skalierung"], n_results=5)

Für den Serverbetrieb genügt chroma run --path ./data --port 8000 oder das offizielle Image chromadb/chroma:1.0.0. Chroma Cloud ist seit 2025 allgemein verfügbar und richtet sich an Teams, die keinen eigenen Server betreiben wollen.

Benchmark-Vergleich: QPS, Latenz und Recall

Die folgenden Werte stammen aus einer eigenen Messung auf einem Hetzner CCX33 (8 vCPU, 32 GB RAM, NVMe), 1 Million Vektoren à 768 Dimensionen, HNSW mit m=16 und ef_search=128, Recall@10 gegen Brute-Force-Referenz. Sie sind als Größenordnung zu lesen, nicht als Laborergebnis.

System	Index	QPS	p95 Latenz	Recall@10	RAM
Qdrant	HNSW + SQ8	3.400	4,1 ms	0,97	1,1 GB
Qdrant	HNSW float32	1.850	7,8 ms	0,99	4,3 GB
Milvus	HNSW	2.900	5,2 ms	0,98	4,6 GB
Milvus	IVF_PQ	6.200	2,4 ms	0,91	0,9 GB
Chroma	HNSW	780	18 ms	0,96	4,5 GB

Die wichtigste Erkenntnis: Quantisierung ist kein Recall-Killer, sondern ein Speicher-Hebel. Qdrant mit SQ8 liefert fast den gleichen Recall wie float32 bei einem Viertel des RAMs – und ist dabei fast doppelt so schnell, weil weniger Daten durch den Cache wandern. IVF_PQ ist der Geschwindigkeitssieger, kostet aber spürbar Recall.

Für belastbare Vergleiche lohnt ein Blick auf VectorDBBench und ANN-Benchmarks. Wichtig: Immer mit dem eigenen Datensatz und den eigenen Filtern testen. Filter können den QPS-Wert um den Faktor 5 drücken – je nachdem, wie selektiv sie sind.

RAM-Bedarf, Quantisierung und Index-Typen

Die Grundformel lautet: Bytes = N × D × 4 für float32. Dazu kommt HNSW-Overhead von etwa 30 bis 50 % für Graph-Kanten. Die folgende Tabelle zeigt die Rohdaten ohne Index-Overhead.

Vektoren	Dimension	float32	SQ8 (int8)	Binary
1 Mio.	768	3,1 GB	0,8 GB	0,1 GB
1 Mio.	1536	6,1 GB	1,5 GB	0,2 GB
10 Mio.	1536	61,4 GB	15,4 GB	1,9 GB
100 Mio.	1536	614 GB	154 GB	19 GB

Die zentralen Index-Parameter:

HNSW m (Nachbarn pro Knoten): 16 ist Standard, 32–64 für hohen Recall bei hoher Dimension. Mehr m bedeutet mehr RAM und langsamere Writes.
HNSW ef_construct: 100–512. Höher = besserer Graph, längere Indexierung.
HNSW ef_search: 64–256. Der wichtigste Latenz-Hebel zur Query-Zeit, ohne Neuindexierung.
IVF nlist: Faustregel 4 × sqrt(N). nprobe: 10–64.
DiskANN: für Korpora, die nicht in den RAM passen. NVMe-SSDs mit hohen IOPS sind Pflicht.

Praxisregel für die Kapazitätsplanung: Rechnen Sie den float32-Wert, halbieren Sie ihn gedanklich durch SQ8 und planen Sie dann noch 40 % Puffer für Index, Payloads und Betriebssystem-Cache ein.

Docker-Setup: Installation in unter 10 Minuten

Qdrant ist ein einzelner Container. Persistenz über ein Volume, fertig.

docker run -d --name qdrant \
  -p 6333:6333 -p 6334:6334 \
  -v $(pwd)/qdrant_storage:/qdrant/storage \
  qdrant/qdrant:v1.12.4

curl http://localhost:6333/healthz   # -> healthz check passed

Chroma läuft ebenfalls als ein Container. Für lokale Entwicklung reicht der Python-Client ohne Server.

docker run -d --name chroma \
  -p 8000:8000 \
  -v $(pwd)/chroma-data:/data \
  chromadb/chroma:1.0.0

curl http://localhost:8000/api/v2/heartbeat

Milvus Standalone benötigt drei Container (Milvus, etcd, MinIO). Das offizielle Compose-File erledigt das:

docker compose up -d
docker compose ps
# milvus-standalone  19530/tcp, 9091/tcp
# milvus-etcd        2379/tcp
# milvus-minio       9000/tcp, 9001/tcp

Für Produktionsbetrieb gilt: Qdrant und Chroma lassen sich problemlos auf einem einzelnen VPS mit 8 vCPU und 32 GB RAM betreiben. Milvus gehört ab dem Standalone-Modus auf eine eigene Maschine – und im Distributed-Modus auf Kubernetes mit dem Milvus Operator.

Kosten im Vergleich: Cloud, Managed und Self-Hosting

Preise ändern sich schnell; die folgenden Werte sind Größenordnungen Stand Q1 2026 und dienen der Orientierung.

Variante	Konfiguration	Kosten/Monat
Qdrant Cloud Free	1 GB RAM Cluster	0 €
Qdrant Cloud	4 GB RAM, 2 vCPU	ca. 30 €
Qdrant Cloud	16 GB RAM, 4 vCPU	ca. 130 €
Zilliz Cloud Free	5 GB Storage, Serverless	0 €
Zilliz Cloud Dedicated	8 GB RAM Cluster	ab ca. 99 €
Chroma Cloud	Free Tier, dann nutzungsbasiert	ab 0 €
Hetzner CCX23 self-hosted	4 vCPU, 16 GB RAM	ca. 30 €
Hetzner CCX33 self-hosted	8 vCPU, 32 GB RAM	ca. 65 €

Die Rechnung ist eindeutig: Self-Hosting auf einem dedizierten VPS ist bei dauerhaftem Betrieb meist 2- bis 4-mal günstiger als Managed Cloud. Dafür fehlen Backups, Monitoring und automatisches Failover – die muss man selbst bauen. Bei schwankender Last oder sehr kleinen Datenmengen sind die Free Tiers von Qdrant und Zilliz dagegen schwer zu schlagen.

Der eigentliche Kostentreiber ist RAM. Wer von float32 auf SQ8 wechselt, spart 75 % Speicher – und kann dadurch oft eine ganze Serverklasse kleiner mieten. Bei 65 € Ersparnis pro Monat amortisiert sich der Migrationsaufwand schnell.

Hybrid Search, Filtering und Multi-Tenancy

Reine Vektorsuche scheitert bei exakten Begriffen: Produktcodes, Aktenzeichen, Eigennamen. Hybrid Search kombiniert Dense-Vektoren mit Sparse-Vektoren (BM25 oder SPLADE) und fusioniert die Ergebnisse per Reciprocal Rank Fusion.

Qdrant bietet dafür die Query API mit prefetch und Fusion.RRF. Milvus nutzt AnnSearchRequest plus RRFRanker oder WeightedRanker. Chroma hat hier nur eingeschränkte Möglichkeiten – wer Hybrid Search braucht, ist bei Chroma falsch.

Beim Filtering unterscheiden sich die Systeme deutlich:

Qdrant: Payload-Indizes für keyword, integer, float, geo und text. Filter werden in den HNSW-Graph integriert.
Milvus: Expression Language wie jahr > 2025 and mandant in [42, 43], ausgewertet vor der Vektorsuche.
Chroma: where-Dict mit $eq, $in, $and, $gt. Funktional, aber ohne Index-Tuning.

Für Multi-Tenancy gibt es zwei Muster: eine Collection mit tenant_id im Payload (bei Qdrant mit is_tenant=True im Index, bei Milvus als Partition Key mit bis zu 1024 Partitionen) oder eine Collection pro Mandant. Ersteres skaliert besser, letzteres isoliert sauberer und erlaubt unterschiedliche Quantisierung pro Mandant.

RAG-Integration, Betrieb und Monitoring

Alle drei Systeme haben offizielle Integrationen für LangChain und LlamaIndex. Die Chunking-Strategie beeinflusst die Qualität stärker als die Wahl der Datenbank: 512 bis 1024 Token pro Chunk mit 10 bis 20 % Overlap ist ein solider Startwert. Ein Reranker wie bge-reranker-v2-m3 oder Cohere rerank-3.5 auf den Top-50-Ergebnissen verbessert den Recall typischerweise um 15 bis 25 % – deutlich mehr, als ein Wechsel zwischen Qdrant und Milvus bringt.

Für den Betrieb gilt es, drei Dinge früh zu regeln:

Backups: Qdrant bietet die Snapshot-API (POST /collections/{name}/snapshots), Milvus das milvus-backup-Tool gegen den Objektspeicher, Chroma schlicht das Kopieren der SQLite-Datei im Stillstand.
Monitoring: Qdrant und Milvus liefern Prometheus-Metriken out of the box; für Milvus existieren fertige Grafana-Dashboards. Chroma ist hier dünn aufgestellt.
Skalierung: Qdrant Distributed arbeitet mit Raft, Sharding und konfigurierbarem Replication Factor. Milvus skaliert über den Kubernetes-Operator. Chroma skaliert nur vertikal – größerer Server oder Sharding auf Anwendungsebene.

Entscheidungsmatrix: Welche Datenbank für welches Projekt

Szenario	Empfehlung
Prototyp, Notebook, unter 100k Vektoren	Chroma (embedded)
Internes Tool, 1–5 Mio. Vektoren, ein Server	Chroma Server oder Qdrant
Produktion bis 50 Mio. Vektoren mit komplexen Filtern	Qdrant
Multi-Tenant-SaaS mit harter Isolation	Qdrant (Collections) oder Milvus (Partition Key)
Über 100 Mio. Vektoren, GPU-Beschleunigung	Milvus
Vektoren größer als der verfügbare RAM	Milvus mit DiskANN oder Qdrant mit mmap
Hybrid Search mit BM25	Qdrant oder Milvus
Bestehende PostgreSQL-Instanz, unter 1 Mio. Vektoren	pgvector statt dedizierter DB

Wer heute neu startet und nicht weiß, wohin die Reise geht, fährt mit Chroma für den Prototyp und Qdrant für die Produktion am wenigsten falsch. Die Migration ist überschaubar, weil beide Cosine-Distanz und Metadaten-Filter unterstützen. Milvus lohnt sich erst, wenn Kubernetes, GPU-Knoten oder Milliarden Vektoren tatsächlich auf der Roadmap stehen – vorher zahlt man Komplexität ohne Gegenwert.

FAQ

Welche Vektordatenbank ist 2026 die beste?

Es gibt keine pauschale Antwort. Für Prototypen ist Chroma wegen des minimalen Setups unschlagbar, für die meisten Produktions-Workloads bis in den zweistelligen Millionenbereich ist Qdrant der beste Kompromiss aus Performance, Filtering und Betriebsaufwand. Milvus gewinnt, sobald echtes Sharding, GPU-Indizes oder mehr als 100 Millionen Vektoren gefordert sind.

Wie viel RAM brauche ich für 1 Million Vektoren?

Bei 768 Dimensionen in float32 sind es rund 3,1 GB reine Vektordaten, mit HNSW-Overhead etwa 4 bis 4,5 GB. Mit Scalar Quantization (int8) sinkt der Bedarf auf etwa 0,8 GB plus Index. Bei 1536 Dimensionen verdoppeln sich die Werte. Planen Sie zusätzlich 30 bis 40 % Puffer ein.

Kann ich Qdrant, Milvus und Chroma ohne Docker installieren?

Ja. Qdrant liefert statische Binaries für Linux und macOS, Chroma installiert sich per pip install chromadb und läuft embedded ohne Server, Milvus bietet mit Milvus Lite eine eingebettete Variante für Python. Für Produktionsbetrieb ist Docker oder Kubernetes trotzdem der übliche Weg.

Was kostet eine Vektordatenbank im Monat?

Die Free Tiers von Qdrant Cloud (1 GB RAM) und Zilliz Cloud (5 GB Storage) reichen für kleine Projekte. Ein 4-GB-Cluster bei Qdrant Cloud liegt bei rund 30 € pro Monat, 16 GB bei etwa 130 €. Self-Hosting auf einem Hetzner-CCX33 mit 8 vCPU und 32 GB RAM kostet etwa 65 € monatlich und trägt deutlich größere Korpora.

Wann reicht pgvector statt einer dedizierten Vektordatenbank?

Solange Sie unter etwa einer Million Vektoren bleiben, keine hohen QPS-Anforderungen haben und Filter ohnehin über SQL laufen, ist pgvector die pragmatischste Lösung – keine zusätzliche Infrastruktur, ein Backup, eine Transaktion. Ab mehreren Millionen Vektoren oder sobald ANN-Parameter-Tuning und Quantisierung nötig werden, wird eine dedizierte Datenbank günstiger als das Hochskalieren der Postgres-Instanz.