Vektor-Datenbanken: Qdrant vs. Weaviate vs. pgvector vs. Milvus

Wenn sich ein Unternehmen entscheidet, RAG (Retrieval-Augmented Generation) über der internen Dokumentation einzusetzen, lautet die erste technische Frage: Wo speichern wir die Vektoren? Die Antwort ist nicht neutral — die Wahl beeinflusst die Antwort-Latenz, die monatlichen Infrastrukturkosten, den Wartungsaufwand und was möglich oder unmöglich ist, wenn sich das Datenvolumen verdoppelt. In der Praxis greifen Teams am häufigsten zu einem dieser vier Lösungen: pgvector, Qdrant, Weaviate und Milvus. Jedes hat einen anderen Fokus, andere Stärken und einen anderen Kontext, in dem es sinnvoll ist.

Dieser Artikel ist kein Benchmark-Duell (öffentlich verfügbare Benchmarks sind naturgemäß abhängig von Hardware, Dimensionalität und Last-Muster). Er ist ein Entscheidungsrahmen — wie man auf Basis dessen auswählt, was das eigene Unternehmen tatsächlich braucht.

Was alle vier gemeinsam haben

Alle vier Lösungen beherrschen Approximate Nearest Neighbor (ANN) Suche mit HNSW-Index, Metadaten-Filterung und Integration mit Standard-Embedding-Modellen. Alle sind Open-Source (Apache 2.0 oder äquivalent) mit der Möglichkeit zum Self-Hosting oder als Managed-Cloud-Variante. Übliche Embedding-Dimensionen von 1 024 oder 1 536 stellen für keine von ihnen ein Problem dar.

Der Unterschied beginnt, wenn man auf Skalierung, Konsistenzanforderungen, bestehende Infrastruktur oder den Bedarf nach hybridem Suchen (Vektor + Keyword) stößt. Dort verzweigen sich die vier Wege.

pgvector — wenn Postgres bereits vorhanden ist

pgvector ist eine PostgreSQL-Erweiterung. Sie existiert nicht als eigenständige Datenbank — sie läuft innerhalb der bestehenden PG-Instanz. Das ist zugleich ihr stärkstes Argument und ihre wesentlichste Einschränkung.

Wann es sinnvoll ist:

Wenn das Unternehmen PostgreSQL betreibt und das Vektorvolumen größenordnungsmäßig Zehnmillionen nicht überschreitet, ist pgvector eine legitime Produktionswahl. Der Vorteil ist grundlegend: Vektoren, strukturierte Daten und Metadaten leben in einer Datenbank, unter einer Transaktion, mit einem Backup-Prozess. Keine Synchronisation zwischen zwei Systemen, keine zusätzliche Infrastruktur.

Die pgvector-Version von Anfang 2026 hat Unterstützung für Sparse Vektoren hinzugefügt und die Performance des IVFFlat-Index deutlich verbessert. Mit HNSW-Index und angemessener Konfiguration schafft die Datenbank auf einem gewöhnlichen Server 5 000 bis 15 000 QPS bei einer Sammlung von rund 10 Millionen Vektoren mit Dimension 1 024. Das ist für die große Mehrheit der B2B-RAG-Deployments über interner Dokumentation ausreichend.

Wo die Grenzen liegen:

Bei Sammlungen über 50 Millionen Vektoren beginnt PG an Architekturgrenzen zu stoßen — ein Rowstore, der für transaktionale Lasten optimiert ist, nicht für reinen ANN-Durchsatz. Die Performance sinkt, und Skalierung erfordert entweder Sharding oder einen Wechsel zu einer anderen Lösung. Ein weiteres Limit: pgvector hat keine native Hybrid-Suche — die Kombination aus Vektor- und Keyword-Suche erfordert das manuelle Zusammenbauen einer Pipeline, etwa über tsvector und manuellen RRF (Reciprocal Rank Fusion).

Typisches Projektprofil: interne Knowledge Base oder Kundensupport, Sammlung von 1–5 Millionen Vektoren, Team, das bereits Postgres verwaltet, mit Präferenz, die Infrastruktur nicht zu erweitern.

Qdrant — Performance und Single-Node Self-Hosting

Qdrant ist eine Datenbank, die von Grund auf für Vektorsuche gebaut wurde. Geschrieben in Rust, mit Fokus auf Performance und unkompliziertes Self-Hosting — Binary oder Docker-Container, keine externen Abhängigkeiten.

Das entscheidende Merkmal, das Qdrant 2026 unterscheidet: native Unterstützung für ColBERT-Style Multi-Vector (Late Interaction), also die Möglichkeit, mehrere Vektoren für ein Dokument zu speichern und über ihre Interaktion zu suchen. Das ermöglicht State-of-the-Art Retrieval ohne externen Reranker-Server — Qdrant erledigt Late Interaction direkt im Index. Für Projekte, bei denen Präzision zählt und kein separater Reranker-Service aufgebaut werden soll, ist das ein erheblicher Vorteil.

Performance-Charakteristik: Bei 10 Millionen Vektoren, 1 024 Dimensionen und einer Last von rund 1 000 QPS bewegen wir uns bei P99-Latenz um 12 ms. Skaliert gut bis zu Hunderten von Millionen Vektoren auf einem Single-Node mit ausreichend RAM, alternativ über Qdrant Cloud Managed Service für größere Installationen.

Hybrid-Suche: Qdrant unterstützt Sparse Vektoren (BM25-Stil) als Erstklassen-Feature — Dense Vektor + Sparse Vektor werden in einem Durchlauf gesucht, ohne manuelles Mischen der Ergebnisse. Für typische Enterprise-RAG-Szenarien (technische Dokumentation, Produktkataloge, Servicehandbücher) ist das ideal — exakte Keywords (Teilenummern, Codes, spezifische Begriffe) fängt der Sparse-Zweig auf, Semantik der Dense-Zweig.

Wann es sinnvoll ist:

Das Team möchte eine Self-Hosted-Lösung, vorhersagbare Latenz, native Hybrid-Suche und keinen verteilten Cluster verwalten. Die Sammlung kann von Millionen bis zu Hunderten von Millionen Vektoren reichen. Operatoren mit einer Person für die Infrastruktur bevorzugen das unkomplizierte Deployment.

Wo die Grenzen liegen:

Bei wirklich großen Sammlungen (Milliarden von Vektoren) ist die native Verteilung im Vergleich zu Milvus eingeschränkt. Das Ökosystem an Integrations-Konnektoren ist kleiner als bei Weaviate.

Weaviate — modulare Hybrid-Suche

Weaviate verfolgt eine andere Philosophie als Qdrant: Jede Fähigkeit ist ein Modul — Embedding-Generierung, Keyword-Indexierung, Reranking, Multimodaler Input. Das nimmt etwas an Einfachheit, gibt aber große Flexibilität ohne Custom-Code.

Schlüsselmerkmal: native Hybrid-Suche (BM25 + Dense Vector + Metadaten-Filter) als Erstklasse in der Query-API. BM25-Index und Vector-Index sind in einem Query-Planer mit automatischem RRF-Fusion integriert. Weaviate glänzt auch mit einer reichhaltigen GraphQL-Query-API, was Teams schätzen, die komplexe Filterung benötigen (Multi-Tenant, Zugriffsrechte, hierarchische Metadaten).

Performance: orientierend 25 000 bis 50 000 QPS bei 10 Millionen Vektoren, P99-Latenz um 16 ms. Die Kosten der Cloud-Variante (Weaviate Cloud) sind höher als bei Qdrant, aber das Team erhält Managed Reranking, Monitoring und SLA.

Wann es sinnvoll ist:

Multi-Tenant-Deployment (mehrere Kunden/Abteilungen in einer Instanz mit isolierten Daten), Bedarf an erweiterter Filterung, Team, das einen Managed Service mit reichhaltigerem Ökosystem schätzt. Auch eine gute Wahl für Projekte mit multimodalem Inhalt, wo das Weaviate-Modul für Image-Embedding Custom-Code einspart.

Wo die Grenzen liegen:

Die modulare Architektur fügt operationale Komplexität hinzu — mehr Konfigurationen, mehr Fehlermöglichkeiten. Für einen einfachen RAG-Use-Case ist Weaviate over-engineered. Der Schema-First-Ansatz (Typen vor dem Indexieren definieren) kann das Prototyping verlangsamen.

Milvus — extreme Skalierung

Milvus ist von der ersten Codezeile an Distributed-First. Es läuft auf Kubernetes, mit etcd für Koordination, S3-kompatiblem Storage für Persistenz und separaten Komponenten für Ingestion, Indexierung und Query. Diese Architektur ist Overhead für kleine Projekte — und Vorteil für große.

Bei Sammlungen im Milliardenbereich erreicht Milvus einen Durchsatz von 100 000+ QPS mit horizontaler Skalierung. GPU-beschleunigtes ANN-Suchen reduziert die Latenz bei großen Indizes weiter. Die Managed-Version — Zilliz Cloud — übernimmt die operative Last.

Wann es sinnvoll ist:

Sammlung über 100 Millionen Vektoren, High-Throughput-Last (E-Commerce-Personalisierung, Empfehlungssysteme, Vektorsuche in Milliarden-Katalogen), Team mit DevOps-Kapazität für den Betrieb des Kubernetes-Stacks.

Wo die Grenzen liegen:

Für ein normales Enterprise-RAG mit Millionen von Vektoren ist Milvus unnötiger Overhead. Eine minimale Produktionsinstallation erfordert mehrere Komponenten — etcd-Cluster, MinIO/S3, Query-Nodes, Data-Nodes. Für ein kleines Team ist das zu viel Infrastruktur. Hybrid-Suche existiert, ist aber weniger reibungslos als bei Qdrant oder Weaviate.

Entscheidungsrahmen: Drei Fragen vor der Wahl

Statt eines Tabellenvergleichs (wo jedes Feld Kontext erfordert) empfehlen wir, drei Fragen der Reihe nach zu beantworten:

1. Wie groß ist die Sammlung jetzt und in 2 Jahren?

• Bis 5 Millionen Vektoren und vorhandenes Postgres → pgvector zuerst ausprobieren. Neue Infrastruktur wird vermieden.
• 5 Millionen bis Hunderte von Millionen → Qdrant oder Weaviate nach den folgenden Kriterien.
• Milliarden von Vektoren oder 100 000+ QPS → Milvus / Zilliz Cloud.

2. Wie viele Personen verwalten die Infrastruktur?

• Ein Entwickler oder kleines Team → Qdrant (einfaches Self-Hosting, Binary/Docker, minimale Abhängigkeiten).
• Team mit DevOps-Kapazität, das einen Managed Service bevorzugt → Weaviate Cloud oder Zilliz Cloud.
• Kubernetes-natives Team mit Erfahrung in verteilten Systemen → Milvus.

3. Wie ist die Struktur der Abfragen?

• Reine semantische Suche → jede dieser DBs.
• Hybrid (Keyword-Präzision + Semantik) → Qdrant (Sparse + Dense nativ) oder Weaviate (BM25 + Dense nativ). Bei Verwendung von pgvector muss Hybrid manuell zusammengebaut werden.
• Multi-Tenant mit isolierten Daten, komplexe Filterung → Weaviate hat die ausgereifteste Query-Planung.
• ColBERT / Multi-Vector Late Interaction → Qdrant als einziges der vier im Jahr 2026 nativ.

Performance-Zahlen im Kontext

Öffentlich verfügbare Benchmarks (beispielsweise ann-benchmarks.com und weitere öffentliche Vergleiche) zeigen orientierend:

Bei einer Last von rund 1 000 QPS auf einer Sammlung von 10 Millionen Vektoren mit 1 024 Dimensionen:

• pgvector: 5 000–15 000 QPS maximal, P99-Latenz variabel je nach Hardware
• Qdrant: 30 000–80 000 QPS, P99 um 12 ms
• Weaviate: 25 000–50 000 QPS, P99 um 16 ms
• Milvus: 100 000+ QPS mit horizontaler Skalierung, P99 um 18 ms (Distributed Setup)

Diese Zahlen sind stark orientierend — tatsächliche Ergebnisse hängen von der Vektor-Dimensionalität, der Indexierungs-Strategie (HNSW-Parametern), der Hardware (Speicher, CPU/GPU), dem Last-Muster und davon ab, ob es sich um Single-Tenant- oder Multi-Tenant-Last handelt. Ein Benchmark aus einem anderen Projekt ist nur der Ausgangspunkt für eigene Messungen.

Die monatlichen Kosten für Cloud-Managed-Varianten bewegen sich bei typischer Enterprise-RAG-Last (10 Millionen Vektoren, ~1 000 QPS) größenordnungsmäßig im niedrigen vierstelligen Euro-Bereich — mit deutlichen Unterschieden je nach Anbieter und Region. Self-Hosting auf eigenen Servern senkt die variablen Kosten, fügt aber fixe Betriebskosten hinzu.

Wo pgvector positiv überrascht

Einer der häufigsten Mythen im Umfeld von DACH/EU-Unternehmen: „pgvector ist nur eine Übergangslösung für PoCs". In der Praxis ist das nicht so. Wir haben bei Kunden aus Fertigung und Logistik RAG-Deployments über 2–3 Millionen Vektoren in Produktion auf pgvector gesehen, die reibungslos laufen — einzige Motivation war der vorhandene PostgreSQL-Cluster und ein Team ohne Kapazität für neue Infrastruktur.

Entscheidend für gute pgvector-Performance in Produktion: HNSW-Index (nicht IVFFlat), korrekte Konfiguration von maintenance_work_mem für den Index-Build, und Partitionierung falls die Sammlung wächst. Mit diesen Einstellungen bewältigt pgvector die meisten Enterprise-internen RAG-Szenarien ohne Umstieg.

Wo pgvector wirklich nicht ausreicht: fortgeschrittene Hybrid-Suche, Multi-Vector / ColBERT Retrieval, und Sammlungen in den Zehnmillionen, wo die Performance der Retrieval-Schicht für die UX kritisch ist (Sub-20-ms-Latenz).

Integration mit RAG-Frameworks

Alle vier Datenbanken haben eine Erstklassen-Integration in LlamaIndex und LangChain. LlamaIndex verfügt über native QdrantVectorStore, WeaviateVectorStore, PGVectorStore und MilvusVectorStore mit konsistentem Interface — eine Migration zwischen DBs ist ein Refaktor auf Ebene einer einzigen Konfigurationszeile, nicht der gesamten Pipeline.

Zur Wahl des Frameworks und Evaluierung der RAG-Pipeline-Qualität verweisen wir auf RAG-Pipeline — 3 Einstellungen, die über Qualität entscheiden — dort werden Chunking-Strategien, Embedding-Upgrade und Reranking detailliert besprochen, die unabhängig von der Wahl der Vektor-DB sind.

Das Embedding-Modell ist eine eigenständige Entscheidung — zu seiner Auswahl siehe Embedding-Modell auswählen und zur Hybrid-Search-Kombination aus BM25 und Vektoren Hybrid-Suche (BM25 + Vektoren + Reranking).

Häufige Fragen

Kann ich mit pgvector starten und später auf Qdrant migrieren?

Ja, und das ist ein gängiges Muster. Die LlamaIndex-Abstraktion des Vector Store ist eine ausreichend dünne Schicht — die Migration erfordert ein erneutes Ingesten der Vektoren (Reindexierung der Dokumente) und eine Änderung der Store-Konfiguration. Pipeline-Logik, Chunking und Embedding-Modell bleiben unverändert. Solange die Originaltexte und Metadaten in einer relationalen DB gespeichert sind, ist die Reindexierung meistens ein Skript, keine monatelange Arbeit.

Ist Qdrant wirklich schneller als Weaviate für meine Last?

Das hängt vom Last-Muster ab. Qdrant zeigt Vorteile in Single-Tenant-Szenarien mit uniformen Abfragen. Weaviate kann vergleichsweise besser sein bei komplexer Multi-Tenant-Filterung, wo sein Query-Planer den Schnittpunkt aus Vektor- und Keyword-Filter optimiert. Wir empfehlen, einen eigenen Benchmark auf einer repräsentativen Stichprobe der eigenen Daten durchzuführen — 1 Stunde Messung auf dem eigenen Korpus ist wertvoller als jeder öffentliche Benchmark.

Brauchen wir Milvus bei 50 Millionen Vektoren?

Wahrscheinlich nicht. Qdrant und Weaviate bewältigen Hunderte von Millionen Vektoren auf einem gut konfigurierten Single-Node-Server. Milvus ist gerechtfertigt bei Milliarden von Vektoren oder beim Bedarf nach 100 000+ QPS, wo die verteilte Architektur tatsächlich eine Ersparnis bringt. Bei 50 Millionen Vektoren ist Milvus eher Overhead als Lösung.

Beeinflusst die Wahl der Vektor-DB die Qualität der RAG-Antworten?

Direkt kaum — die Antwortqualität hängt primär von der Qualität des Chunkings, des Embedding-Modells und des Rerankers ab, nicht davon, welche DB die Vektoren speichert. Indirekt ja: Wenn die Vektor-DB hohe Latenz oder niedrigen Recall bei gefilterter Suche hat, gelangen schlechtere Kontextfragmente in das generative Modell. Die DB-Wahl beeinflusst vor allem Performance, Kosten und operative Last — nicht die Retrieval-Pipeline-Logik selbst.

Funktioniert pgvector auch für deutschen Text?

Ja — eine Vektor-Datenbank ist sprachagnostisch. Sie speichert und sucht Vektoren unabhängig von der Sprache. Sprachliche Eigenschaften liegen in der Verantwortung des Embedding-Modells, nicht der DB. Für mehrsprachige Deployments (DE, SK, CZ) empfehlen wir Multilingual-Modelle wie BGE-M3 oder Qwen3-Embedding — mehr dazu im Artikel Embedding-Modell auswählen.

*MP Industrial Solutions unterstützt Unternehmen bei der Konzeption und dem Deployment einer RAG-Infrastruktur, die der tatsächlichen Last entspricht — von der Beurteilung, ob pgvector ausreicht, bis hin zum Produktions-Deployment von Qdrant oder Weaviate auf On-Prem-Servern. Wenn Sie ein Deployment planen oder Performance-Probleme mit einer bestehenden Vektorschicht lösen möchten, vereinbaren wir gerne ein unverbindliches Erstgespräch.*