Vektordatenbanken für RAG im Vergleich: pgvector, Qdrant, Milvus und OpenSearch

pgvector, Qdrant, Milvus und OpenSearch im Vergleich

Für ein RAG-System im Unternehmen mit einigen Millionen Chunks genügt PostgreSQL mit pgvector, wenn PostgreSQL bereits im eigenen Haus läuft und für gefilterte Abfragen iterative Index-Scans eingeschaltet sind. Qdrant und Milvus sind für die Vektorsuche gebaute Datenbanken und wenden Metadatenfilter innerhalb der Suche oder vor ihr an; Milvus dokumentiert seinen Distributed-Modus für „100 Millionen bis zu Dutzenden Milliarden Vektoren“. OpenSearch eignet sich für ein Unternehmen, das bereits einen OpenSearch-Cluster betreibt und Stichwort- und Vektorsuche in einer Abfrage verbinden will.

Unser Leitfaden zu einer privaten ChatGPT-Alternative für Unternehmen ordnet die Datenbank in den gesamten Stack ein, und unser Vergleich von Fine-Tuning und RAG behandelt die Frage, ob Retrieval der richtige Ansatz ist.

Dokumentation, Release-Seiten und LICENSE-Datei jedes Projekts, abgerufen am 6. Oktober 2026: pgvector 0.8.7 (PGXN, 1. Oktober 2026), Qdrant v1.19.2 (5. Oktober 2026), Milvus 3.0.2 (20. September 2026), OpenSearch 3.9.0 (29. September 2026).

Indextypen: HNSW, IVF, DiskANN und Quantisierung

Alle vier bieten HNSW, einen Graphindex, der exakte Ergebnisse gegen Geschwindigkeit eintauscht. pgvector bietet ihn neben IVFFlat an; laut README hat HNSW „eine bessere Abfrageleistung als IVFFlat (gemessen am Zielkonflikt zwischen Geschwindigkeit und Recall), aber längere Build-Zeiten und verbraucht mehr Speicher“. Der Typ vector lässt sich bis 2.000 Dimensionen indexieren, halfvec bis 4.000; für größere Embeddings nennt die README binäre Quantisierung, das Indexieren von Teilvektoren und Dimensionsreduktion.

Qdrant „verwendet derzeit nur HNSW als Index für dichte Vektoren“ und spart Speicher durch Quantisierung: Skalare Quantisierung speichert jeden Wert als 8-Bit-Ganzzahl, eine Reduktion um den Faktor vier, während binäre Quantisierung und TurboQuant bis zum Faktor 32 erreichen. Milvus führt FLAT, die IVF- und HNSW-Familien mit quantisierten Varianten, SCANN, vier GPU-Indizes, AISAQ und DISKANN auf; DISKANN hält seinen Graphen auf dem Datenträger, für Datensätze, die „zu groß, um in den Speicher zu passen“ sind. OpenSearch baut HNSW mit der Engine Lucene oder Faiss und IVF mit Faiss; sein Modus on_disk quantisiert Float-Vektoren standardmäßig auf 1 Bit und bewertet die Top-Treffer mit Vektoren in voller Präzision neu, die vom Datenträger gelesen werden.

Filtern nach Berechtigungen während der Vektorsuche

Unser Leitfaden zu RAG auf Unternehmensdaten erklärt, warum Zugriffsrechte beim Abruf durchgesetzt werden, wobei jeder Chunk die Nutzer und Verzeichnisgruppen mitführt, die seine Quelle lesen dürfen. Ein approximativer Index sammelt eine begrenzte Zahl von Kandidaten aus seinem Graphen. Läuft der Berechtigungsfilter erst danach und nur auf diesen Kandidaten, erhält ein Nutzer, der einen kleinen Teil des Korpus lesen darf, weniger Ergebnisse als angefordert.

Die README von pgvector hält fest, dass bei approximativen Indizes „die Filterung nach dem Scan des Index angewendet wird“. Mit HNSW und dem Standardwert 40 für hnsw.ef_search bleiben bei einer Bedingung, die auf 10 % der Zeilen zutrifft, im Durchschnitt „nur 4 Zeilen“ übrig. Iterative Index-Scans, eingeführt mit Version 0.8.0 vom Oktober 2024, scannen weiter, bis genug Zeilen die Bedingung erfüllen, standardmäßig bis zu 20.000 besuchte Tupel; SET hnsw.iterative_scan = strict_order schaltet sie ein. Für Filter, die auf wenige Zeilen zutreffen, schlägt die README einen gewöhnlichen Index auf der Filterspalte vor, der eine exakte Suche ergibt; für ein Array erlaubter Gruppen unterstützt der GIN-Index von PostgreSQL den Überlappungsoperator &&.

Policies für Sicherheit auf Zeilenebene (Row Security Policies) können die Regel in der Datenbank durchsetzen. Superuser und Rollen mit BYPASSRLS umgehen sie immer, ebenso der Eigentümer der Tabelle, sofern die Tabelle nicht auf FORCE ROW LEVEL SECURITY gesetzt ist. PostgreSQL prüft eine Policy an jeder Zeile, die der Scan zurückgibt; bei einem HNSW-Index wirkt sie deshalb wie jeder andere Filter und braucht ebenfalls iterative Scans.

Qdrant filtert während der Graphsuche. Es erweitert HNSW „um zusätzliche Kanten auf Basis indexierter Payload-Werte“, und seine Dokumentation fordert dazu auf, Payload-Indizes anzulegen, bevor Daten eingespielt werden. Ein Abfrageplaner schätzt, auf wie viele Punkte ein Filter zutrifft, liest sie unterhalb eines Schwellenwerts über den Payload-Index ein und bewertet sie exakt. Seit v1.16.0 kann eine Abfrage ACORN einschalten, das standardmäßig aus ist; ACORN durchsucht die Nachbarn von Nachbarn, wenn direkte Nachbarn herausgefiltert sind, und „verbessert die Suchgenauigkeit auf Kosten der Performance“. Die JWT-Token von Qdrant gewähren Lese- oder Lese-Schreib-Rechte je Collection, den Filter je Nutzer fügt also Ihre Anwendung jeder Abfrage hinzu.

Milvus wendet den Filter vor der Suche an, und seine Dokumentation nennt die Schritte „Entitäten filtern, die den Filterbedingungen entsprechen“ und „ANN-Suche innerhalb der gefilterten Entitäten durchführen“. Bei komplexen Ausdrücken sucht "hints": "iterative_filter" in den Suchparametern in Iterationen und filtert, was jede Iteration liefert, bis genug Ergebnisse gefunden sind. Erlaubte Gruppen werden mit ARRAY_CONTAINS_ANY geprüft, und RBAC endet auf Ebene der Collection, also kommt auch hier der Filter je Nutzer aus der Anwendung.

In OpenSearch setzt Efficient Filtering den Filter in die knn-Klausel und wendet ihn während der Vektorsuche an, was „sicherstellt, dass k Ergebnisse zurückgegeben werden (sofern es insgesamt mindestens k Ergebnisse gibt)“, mit Lucene-HNSW ab 2.4 und Faiss-HNSW ab 2.9. Liefert die approximative Suche mit Faiss weniger als k Ergebnisse, weicht die Engine auf eine exakte Suche über die gefilterten Dokumente aus. Ein Post-Filter „kann bei einem restriktiven Filter deutlich weniger als k Ergebnisse zurückgeben“. Sicherheit auf Dokumentebene (Document-Level Security) begrenzt über eine Rollenabfrage mit Variablen wie ${user.name}, was eine Rolle abrufen kann; ihre Dokumentation erwähnt k-NN-Abfragen nicht, prüfen Sie also in einem Test, ob ein eingeschränkter Nutzer weiterhin k Ergebnisse erhält.

Assistenten, die im Rahmen unserer Leistung Private AI/ML entstehen, nennen die Quelle und beachten die Zugriffsrechte jedes Nutzers. Beschreiben Sie im Formular unten, wo Ihre Dokumente liegen und wie der Zugriff darauf vergeben wird.

Hybride Suche: Stichwörter und Vektoren unter einem Filter

Teilenummern und Fehlercodes brauchen neben der Vektorähnlichkeit einen Stichwortabgleich, und der Berechtigungsfilter muss beide Teile abdecken, sonst kommen gesperrte Chunks über die Stichwortsuche zurück. Die README von pgvector kombiniert die Vektorsuche mit der „Postgres-Volltextsuche für hybride Suche“, zusammengeführt per Reciprocal Rank Fusion (RRF) oder mit einem Cross-Encoder; eine Policy für Sicherheit auf Zeilenebene erfasst beide SQL-Abfragen, während eine WHERE-Bedingung in jede der beiden geschrieben werden muss. Qdrant führt Kandidaten aus Prefetches über dichte und dünnbesetzte Vektoren per RRF oder verteilungsbasierter Score-Fusion zusammen, mit einem IDF-Modifier für Gewichte nach Art von BM25; jeder Prefetch nimmt einen eigenen Filter an, wiederholen Sie den Berechtigungsfilter also in jedem.

Milvus wandelt ein Textfeld mit einer eingebauten BM25-Funktion in dünnbesetzte Vektoren um. In seiner hybriden Suche hat jeder AnnSearchRequest einen eigenen expr, der Berechtigungsausdruck gehört also in jede dieser Anfragen. In OpenSearch führt die hybride Suche (eingeführt mit 2.11) eine hybride Abfrage mit bis zu fünf Abfrageklauseln aus, und ihr filter auf oberster Ebene gilt für „alle Unterabfragen der hybriden Abfrage“.

Speicher je Million Vektoren: die dokumentierten Formeln

Die Rohgröße ist Zahl der Vektoren × Dimensionen × Byte je Wert; eine Million float32-Embeddings mit 1.024 Dimensionen brauchen also 1.000.000 × 1.024 × 4 = 4.096.000.000 Byte oder 4,10 GB, bei 768 Dimensionen 3,07 GB. Jedes Projekt dokumentiert eine eigene Schätzung für den Index.

Unsere Rechnung nach der README von pgvector, Qdrants Seite zur Kapazitätsplanung (m = 16), der Milvus-Seite „Index explained“ (ihr Beispiel mit Grad 32) und den k-NN-Seiten von OpenSearch (m = 16); d = Dimensionen, m = HNSW-Verbindungen je Knoten; GB = 10⁹ Byte; ohne Text, Metadaten, Zeilen-Overhead und Replikate.

Die Reserve bei Qdrant deckt „den Page Cache des Betriebssystems, den Laufzeit-Overhead von Qdrant und temporäre Arbeit während der Optimierung“ ab, und Replikate vervielfachen die Zahl der Punkte. OpenSearch gibt Faiss-Indizes einen Anteil des Speichers, der nach dem Java-Heap übrig bleibt, standardmäßig 50 %. Im Beispiel seiner Dokumentation bleiben auf einer Maschine mit 100 GB und einem Heap von 32 GB 68 GB übrig, von denen das k-NN-Plugin 34 GB nutzt; nach unserer Rechnung fasst das rund 7,3 Millionen Vektoren mit 1.024 Dimensionen bei m = 16. Der HNSW-Index von pgvector speichert jeden Vektor neben seinen Graphverbindungen erneut. Bauen Sie einen Testindex und lesen Sie seine Größe mit pg_relation_size aus; Indizes werden „deutlich schneller aufgebaut, wenn der Graph in maintenance_work_mem passt“.

Für eine solche Plattform wählen wir GPU-Server, schnellen Storage und Low-Latency-Netzwerk aus und liefern sie, vom Einzelserver bis zum Cluster. Schicken Sie uns die Zahl der Chunks, die Dimensionen der Embeddings und das erwartete Wachstum über das Formular unten.

GPU-Beschleunigung: Indexaufbau und GPU-Indizes

Milvus hat vier GPU-Indizes, GPU_CAGRA, GPU_IVF_FLAT, GPU_IVF_PQ und GPU_BRUTE_FORCE. GPU_CAGRA belegt etwa das 1,8-Fache des Speichers der ursprünglichen Vektordaten, und mit adapt_for_cpu wird er auf der GPU aufgebaut und auf der CPU durchsucht. Seit v1.13.0 kann Qdrant seine Indizes auf GPUs aufbauen, über Vulkan 1.3 in eigenen gpu-nvidia-Images, mit bis zu 16 GB Vektordaten je GPU und Indexierungsdurchlauf. OpenSearch 3.0 hat einen GPU-beschleunigten Remote-Build-Dienst für Faiss-HNSW-Indizes eingeführt, mit einem Amazon-S3-Repository als Zwischenspeicher. Die README von pgvector erwähnt keine GPUs. Bei einigen Millionen Chunks dimensionieren Sie die GPUs zuerst für die Sprach- und Embedding-Modelle; der Indexaufbau auf GPUs wird wichtig, sobald ein Neuaufbau nicht mehr ins Wartungsfenster passt.

Betrieb: Hochverfügbarkeit, Upgrades und Backups

pgvector „nutzt das Write-Ahead-Log (WAL), das Replikation und Point-in-Time-Recovery ermöglicht“; Ihre PostgreSQL-Standbys und die Archivierung erfassen die Vektoren also mit. Version 0.8.7 vom 1. Oktober 2026 behebt einen Pufferüberlauf beim Aufbau von IVFFlat-Indizes (CVE-2026-103484), und das Projekt rät allen Nutzern früherer Versionen zum Upgrade; ein Upgrade endet mit ALTER EXTENSION vector UPDATE; in jeder Datenbank. Der Replikationsfaktor von Qdrant steht standardmäßig auf 1, „was bedeutet, dass automatisch keine zusätzliche Kopie vorgehalten wird“. Mit einem Faktor von mindestens 2 für jede Collection lässt sich ein Cluster ohne Ausfallzeit aktualisieren, indem die Knoten nacheinander neu gestartet werden, und jedes Upgrade führt über den neuesten Patch jeder dazwischenliegenden Nebenversion. Verbindungen bleiben unverschlüsselt, bis TLS aktiviert ist.

Milvus Standalone läuft aus einem Docker-Image und Milvus Distributed auf Kubernetes, mit Metadaten in etcd, Daten in einem Objektspeicher wie MinIO und einem Write-Ahead-Log auf Woodpecker, Kafka oder Pulsar. Konsistente Backups von pgvector, Qdrant und Milvus behandelt unser Artikel zum Backup eines KI-Servers.

Wann PostgreSQL mit pgvector genügt

pgvector genügt, wenn PostgreSQL bereits mit Replikation und Backups im Produktivbetrieb läuft, die Vektoren in den Arbeitsspeicher eines Servers passen, das Embedding-Modell höchstens 2.000 Dimensionen hat (4.000 als halfvec) und die Berechtigungen in Tabellen liegen, die eine Abfrage per Join einbinden oder eine Policy für Sicherheit auf Zeilenebene durchsetzen kann. Nach unserer Rechnung ergeben 300.000 Dokumente mit durchschnittlich zehn Chunks 3 Millionen Chunks oder 12,3 GB Vektordaten bei 1.024 Dimensionen, und ein HNSW-Index speichert die Vektoren ein zweites Mal. Auch Private AI Services von VMware indexiert seine Wissensdatenbanken in pgvector, wie unser Artikel zu VMware Private AI Foundation beschreibt.

Eine eigenständige Engine ist sinnvoll, wenn die Vektoren über den Arbeitsspeicher eines Servers hinauswachsen, wenn Quantisierung mit eingebautem Rescoring den Speicher im Budget halten muss, wenn Filter während der Graphsuche statt danach greifen sollen oder wenn die Vektoren getrennt von den transaktionalen Datenbanken laufen sollen. OpenSearch passt dort, wo sein Cluster und sein Sicherheitsmodell bereits bestehen und die Stichwortsuche ebenso zählt wie die Ähnlichkeit.

Was wir tun

Im Rahmen unserer Leistung Private AI/ML baut unser Engineering-Partner Vixen.UNO RAG-Plattformen, deren Assistenten mit Quellenangabe und unter Beachtung der Zugriffsrechte jedes Nutzers antworten, mit Query-Log sowie Daten- und Berechtigungsverwaltung. Das erste Gespräch ist kostenlos; das kostenpflichtige technische Assessment umfasst die Lösungsarchitektur, die Modell- und GPU-Auswahl und einen Pilotplan mit Metriken. Der Preis steht vor Beginn fest. Eurokommerz hält den Vertrag und liefert die KI-Server, den Storage und das Netzwerk, mit EU-Rechnungsstellung und Garantie nach europäischem Recht. Die Plattform läuft auf Ihren Servern oder auf dedizierter Hardware in einem Tier-3-Rechenzentrum in Litauen.

FAQ