Vektordatenbanken im Vergleich: Qdrant, pgvector, Weaviate, Milvus, LanceDB
Welche Vektordatenbank passt zu welchem Szenario? Dieser Vergleich zeigt die fünf wichtigsten Optionen im Mittelstand 2026 — mit Fokus auf Indexing, Filter-Performance, Betriebsaufwand und Compliance.
Vektordatenbanken sind das Fundament jeder RAG-Pipeline und vieler semantischer Suchsysteme. Die Auswahl entscheidet nicht nur über Retrieval-Qualität, sondern über Jahre an Betriebskosten, Skalierungsaufwand und Compliance-Risiken. Dieser Artikel bewertet Qdrant, pgvector, Weaviate, Milvus und LanceDB entlang realer B2B-Anforderungen.
Entscheidungsmatrix auf einen Blick
Vor dem Detailvergleich hilft eine nüchterne Übersicht. Die Zahlen beziehen sich auf typische Mittelstands-Workloads mit Embedding-Dimensionen 768 bis 1536.
| System | Sweet-Spot | Index | Filter | Betrieb | Lizenz |
|---|---|---|---|---|---|
| Qdrant | 1M – 50M Vektoren | HNSW + Scalar/PQ | stark (Filterable HNSW) | niedrig (1 Container) | Apache 2.0 |
| pgvector | <2M Vektoren | HNSW, IVFFlat | mittel | sehr niedrig (Postgres) | PostgreSQL License |
| Weaviate | 1M – 100M Vektoren | HNSW + PQ/BQ | stark, inverted index | mittel | BSD-3 |
| Milvus | 10M – 10B Vektoren | HNSW, IVF, DiskANN | gut | hoch (verteilt) | Apache 2.0 |
| LanceDB | Embedded, <10M | IVF-PQ | mittel | minimal (Datei-basiert) | Apache 2.0 |
Indexing-Algorithmen: HNSW, IVF, DiskANN
Der Index entscheidet, wie schnell eine ANN-Suche antwortet und wie viel RAM die Datenbank belegt. Drei Familien dominieren.
HNSW — Hierarchical Navigable Small World
HNSW baut einen mehrschichtigen Graphen, in dem jeder Vektor mit seinen Nachbarn verbunden ist. Die Suche springt auf der obersten Schicht grob zum Ziel und verfeinert nach unten. Vorteil: extrem niedrige Latenzen (unter 10 ms für Millionen Vektoren), hohe Recall-Werte von 0,95+. Nachteil: der gesamte Graph muss im RAM liegen. Ein Graph mit 10 Millionen Vektoren à 1024 Float32 plus Graph-Struktur verbraucht etwa 50 GB.
IVF — Inverted File Index
IVF partitioniert den Vektorraum in Cluster und speichert pro Cluster eine Liste von Vektoren. Eine Abfrage prüft nur die nächsten nprobe Cluster. In Kombination mit Product Quantisierung (IVF-PQ) sinkt der Speicherbedarf um Faktor 8 bis 32 — auf Kosten von Recall-Verlusten von zwei bis fünf Prozentpunkten. Gut für zehn bis hundert Millionen Vektoren.
DiskANN
DiskANN hält nur einen kleinen Teil des Graphen im RAM, der Rest liegt auf NVMe. Damit skalieren einzelne Knoten auf Milliarden Vektoren. Latenzen liegen bei 20 bis 80 ms. Milvus und proprietäre Systeme wie Turbopuffer nutzen diesen Ansatz für sehr große Bestände.
Faustregel: Unter 10M Vektoren reicht HNSW im RAM. Zwischen 10M und 100M wird PQ-Quantisierung relevant. Über 100M Vektoren wird disk-basiertes Indexing (DiskANN) wirtschaftlich notwendig.
Filter-Performance und Payload
Reine Vektor-Suche ist selten. In der Praxis filtert man nach tenant_id, sprache, datum oder access_level. Genau hier trennt sich Spreu vom Weizen.
- Qdrant implementiert „Filterable HNSW": Filter werden während der Graph-Traversierung ausgewertet, nicht nachgelagert. Das bleibt auch bei Cardinalities von einigen Prozent performant.
- Weaviate kombiniert HNSW mit einem separaten Inverted Index auf Payload-Feldern — ähnlich robust.
- pgvector kann per
WHEREfiltern, aber HNSW und Filter arbeiten nicht perfekt zusammen. Bei niedrigen Selektivitäten (unter 10 Prozent) bricht Recall ein. - Milvus bietet Partitions und Scalar-Filter mit akzeptabler Performance.
- LanceDB filtert nachgelagert — solide bei hohen Selektivitäten, schwach bei niedrigen.
Betriebsaufwand und Memory vs. Disk
Der günstigste Index nützt nichts, wenn der Betrieb fünf Menschentage pro Monat bindet. Die Systeme unterscheiden sich hier drastisch.
pgvector
Läuft im bestehenden Postgres-Cluster. Backup, Replikation, Monitoring — alles vorhanden. Für Teams mit Postgres-Erfahrung der kostengünstigste Einstieg. Limit: Bei mehr als etwa zwei Millionen Vektoren wird der RAM-Bedarf für den HNSW-Index zum Flaschenhals, und das Filtern verliert an Präzision.
Qdrant
Ein einzelner Container, klare REST/gRPC-API, gute Prometheus-Metriken. Für 90 Prozent der Mittelstands-Szenarien ausreichend — auch ohne Cluster. Snapshot-Backup eingebaut. Wer Replikation braucht, aktiviert Cluster-Mode.
Weaviate
Feature-reich mit eingebautem GraphQL, Modul-System für Embeddings und Hybrid-Suche. Betriebsaufwand höher als bei Qdrant, aber niedriger als bei Milvus. Gute Wahl, wenn BM25 + Vektor-Suche kombiniert werden sollen.
Milvus
Verteilte Architektur mit mindestens fünf Komponenten (etcd, MinIO, Pulsar, Proxy, Query-Node). Mächtig, aber für Mittelstands-Teams Overkill bei Beständen unter 50 Millionen Vektoren. Zielgröße: Enterprise-Workloads ab 100 Millionen Vektoren oder Multi-Mandanten-SaaS.
LanceDB
Datei-basiert, kein Server. Ideal für Edge, Embedded oder On-Device-Szenarien. Integration in Python/Rust direkt, Daten liegen als Lance-Files im Objekt-Storage. Kein Multi-Writer, daher untauglich für klassische Mehrbenutzer-Anwendungen.
Multi-Tenancy, GDPR und Skalierung
Multi-Mandantenfähigkeit entsteht entweder über Collection per Tenant oder über Payload-Filter. Erstere Variante ist sauberer isoliert, skaliert aber in der Praxis nur bis wenige hundert Tenants. Für SaaS mit Tausenden Kunden führt kein Weg an Filter-basierter Isolation vorbei.
Für die Löschung nach Art. 17 DSGVO ist die Implementierung entscheidend: Ein DELETE muss die Vektoren auch aus dem Index entfernen, nicht nur als „tombstoned" markieren. Qdrant, Weaviate und Milvus räumen Tombstones im Hintergrund weg. Bei pgvector erst nach VACUUM. Backups mit alten Embeddings müssen separat rotiert werden.
Oft übersehen: Embeddings sind personenbezogene Daten, wenn sie aus personenbezogenen Texten berechnet wurden. Die Rückrechnung ist teilweise möglich („embedding inversion"). Daher: Lösch-Prozesse regelmäßig testen und protokollieren.
Empfehlung pro Szenario
Keine Vektordatenbank ist universell „am besten". Die Wahl hängt von Datenvolumen, bestehender Infrastruktur und Kompetenzen im Team ab.
- Mittelstand, <10M Vektoren, Postgres vorhanden: pgvector. Kein Argument für eine zweite Datenhaltung.
- Mittelstand, 1M – 50M Vektoren, neues Projekt: Qdrant. Beste Balance aus Performance, Filter-Qualität und Betriebsaufwand.
- Hybrid-Suche (Vektor + BM25): Weaviate. Inverted Index und Modul-System sparen Eigenentwicklung.
- Enterprise, >100M Vektoren, SaaS mit Tausenden Tenants: Milvus. Horizontale Skalierung und DiskANN.
- Embedded, On-Device oder Edge: LanceDB. Keine Server-Infrastruktur, direkte Python-Integration.
Wer unsicher ist, startet pragmatisch: Erste zwei Millionen Vektoren in pgvector, Migration zu Qdrant ab der ersten Performance-Schwelle. Die API-Abstraktion in LangChain/LlamaIndex macht diesen Wechsel in wenigen Tagen machbar.
Ist Ihre Infrastruktur bereit für Vektor-Suche?
Der KI-Reifegrad-Selbsttest prüft Infrastruktur, Datenstände und Governance — zwölf Fragen, sieben Minuten, mit konkreten Empfehlungen für den nächsten Schritt.
Häufige Fragen
Reicht pgvector für einen Produktivbetrieb?
Für bis zu etwa zwei Millionen Vektoren der Dimension 1024 liefert pgvector mit HNSW-Index akzeptable Latenzen unter 50 ms — vorausgesetzt, genug RAM für den Index. Vorteil: keine zusätzliche Infrastruktur, Joins mit relationalen Daten möglich, DSGVO-Löschung per DELETE. Nachteile sind die geringere Filter-Performance bei hohen Cardinalities und das Fehlen spezieller Quantisierungsoptionen.
Wann ist HNSW nicht mehr die richtige Wahl?
HNSW ist speicherhungrig. Ab etwa 50 Millionen Vektoren der Dimension 1024 wird der RAM-Bedarf unwirtschaftlich. Dann lohnen sich disk-basierte Alternativen wie DiskANN oder IVF-PQ. Diese Indizes halten nur einen kleinen Teil im RAM und lesen den Rest von NVMe. Latenzen steigen von 5 auf 30 bis 80 ms, Speicherbedarf sinkt um Faktor 10.
Wie löscht man Vektoren DSGVO-konform?
Alle genannten Systeme unterstützen harte Löschung per ID oder Filter. Qdrant, Weaviate und Milvus bieten Payload-basierte Löschung. Wichtig ist, dass die Löschung auch aus dem HNSW-Index entfernt wird — bei Weaviate und Qdrant erfolgt das automatisch, bei pgvector erst nach VACUUM. Embeddings in Backups müssen zusätzlich berücksichtigt werden.
Multi-Tenancy pro Collection oder pro Filter?
Collection-per-Tenant bietet harte Isolation und einfache Löschung, skaliert aber schlecht über 500 bis 1000 Tenants hinaus. Filter-basiertes Multi-Tenancy mit tenant_id im Payload skaliert auf Millionen von Tenants, erfordert aber disziplinierte Query-Konstruktion. Qdrant, Weaviate und Milvus unterstützen beide Varianten; Milvus bietet mit Partitions einen Mittelweg.
Die richtige Vektor-DB wählen — ohne Lock-In
Wir bewerten Ihre Datenlage, prüfen Performance-Anforderungen und empfehlen den kosteneffizientesten Weg. Unabhängig, mit belastbarer Begründung.