Qdrant oder pgvector: Die Vektor-Datenbank für self-hosted RAG wählen
KI-generiert, menschlich reviewt
Am Anfang jedes RAG-Projekts steht eine Architekturentscheidung, die später schwer zu revidieren ist: Wo landen die Vektoren? Die beiden naheliegenden Optionen für ein System auf eigener Infrastruktur heißen Qdrant und pgvector. Beide lassen sich self-hosted betreiben, beide liefern Ähnlichkeitssuche über Embeddings — und trotzdem führen sie zu spürbar unterschiedlichen Systemen. Dieser Artikel ordnet die Wahl Qdrant vs. pgvector entlang der Kriterien ein, die im Betrieb tatsächlich zählen, statt entlang von Feature-Listen.
Zur Einordnung: In einem System für Retrieval-Augmented Generation (RAG) werden Dokumente in Abschnitte zerlegt, als Embeddings gespeichert und zur Laufzeit nach semantischer Ähnlichkeit zur Nutzerfrage abgerufen. Der Vektor-Store ist die Komponente, die diesen Abruf leistet. Seine Wahl entscheidet weniger über die reine Trefferqualität — die hängt stärker an Chunking, Embedding-Modell und Retrieval-Strategie — als über Filterbarkeit, Skalierungspfad und den Aufwand, den Sie dauerhaft im Betrieb tragen.
Was die Wahl wirklich entscheidet
Der zugrunde liegende Suchalgorithmus unterscheidet die beiden kaum: Beide nutzen approximative Nearest-Neighbor-Suche über einen HNSW-Index und liefern für typische Wissensbestände gute Ergebnisse. Die relevante Frage ist deshalb nicht „welche Datenbank sucht besser”, sondern „welche passt zu Ihrer bestehenden Landschaft und Ihrem Betriebsmodell”.
Zwei Faktoren dominieren die Entscheidung. Erstens: Betreiben Sie bereits PostgreSQL? Dann ist die Frage, ob ein zweites zustandsbehaftetes System den Zugewinn rechtfertigt. Zweitens: Wie anspruchsvoll sind Filterung, Hybrid Search und Skalierung in Ihrem Anwendungsfall? Je näher die Vektorsuche am Kern Ihres Produkts liegt, desto eher zahlt sich Spezialisierung aus.
pgvector — die Erweiterung Ihrer Postgres-Landschaft
pgvector ist eine Erweiterung für PostgreSQL. Sie fügt einen Vektor-Datentyp und passende Indizes hinzu — die Vektoren liegen als Spalte in einer ganz normalen Tabelle. Damit steht Ihnen der volle Funktionsumfang von SQL zur Verfügung: Metadaten filtern Sie mit WHERE, Sie verknüpfen Vektortreffer per JOIN mit relationalen Daten, und alles läuft in denselben Transaktionen wie der Rest Ihrer Anwendung.
Der eigentliche Vorteil ist betrieblicher Natur: kein zusätzliches System. Wer Postgres ohnehin sichert, überwacht und aktualisiert, bekommt die Vektorsuche ohne neue Komponente im Stack. Ein Dokument und seine Embeddings sind konsistent, weil sie in derselben Datenbank leben — kein Abgleich zweier Speicher, keine Frage, welcher Stand gerade gilt.
Die Grenzen zeigen sich mit wachsendem Bestand und steigender Filterkomplexität. pgvector erbt das Skalierungsmodell von Postgres: primär vertikal, auf einem Knoten. Sehr große Vektormengen oder aufwendige Filter treffen dort früher an Grenzen als bei einem System, das für genau diese Last gebaut wurde.
Qdrant — die spezialisierte Vektor-Datenbank
Qdrant ist eine dedizierte Vektor-Datenbank. Sie speichert zu jedem Vektor eine strukturierte Payload und ist von Grund auf darauf ausgelegt, während der Ähnlichkeitssuche zu filtern — mit eigenen Indizes auf den Payload-Feldern. Das macht einen Unterschied, wenn Sie große Bestände nach Metadaten wie Mandant, Zeitraum oder Berechtigung einschränken und dabei Antwortzeit und Trefferqualität halten wollen.
Hybrid Search — die Kombination aus dichter (semantischer) und dünnbesetzter (schlüsselwortbasierter) Suche — ist nativ vorgesehen, samt Fusion der Ergebnislisten. Für Horizontal-Skalierung bringt Qdrant Sharding und Replikation mit; der Pfad zu sehr großen Beständen ist damit vorgezeichnet.
Der Preis dieser Spezialisierung ist ein zweites zustandsbehaftetes System. Es will betrieben, überwacht, gesichert und aktualisiert werden — mit eigenem Release-Zyklus und ohne transaktionale Kopplung an Ihre relationalen Daten. Die Konsistenz zwischen Primärdaten und Vektoren müssen Sie selbst herstellen, etwa über Ihre Ingestion-Pipeline.
Die Entscheidungskriterien: Qdrant vs. pgvector
Die folgende Tabelle stellt die Kriterien gegenüber, die in der Praxis den Ausschlag geben. Sie ist qualitativ zu lesen — die konkrete Grenze hängt an Ihrem Bestand, Ihrer Hardware und Ihren Antwortzeit-Anforderungen.
| Kriterium | pgvector | Qdrant |
|---|---|---|
| Filterung & Metadaten | Volles SQL (WHERE, JOIN); Filter-Performance bei großen Beständen begrenzt | Payload-Indizes, Filterung während der Suche; auf große, gefilterte Bestände ausgelegt |
| Hybrid Search | Über Postgres-Volltextsuche kombinierbar, aber Eigenbau | Nativ (dichte + dünnbesetzte Vektoren, Fusion) |
| Skalierung | Primär vertikal, Postgres-Modell | Horizontal via Sharding & Replikation |
| Ops-Aufwand | Keine neue Komponente, wenn Postgres läuft | Zusätzliches System zu betreiben und zu überwachen |
| Backup & Upgrades | Postgres-Standard (pg_dump, PITR), ein Zyklus | Eigene Snapshots, eigener Release-Zyklus |
| Postgres-Anbindung | Nativ, transaktional, gemeinsame Queries | Getrennter Speicher, IDs/Konsistenz selbst pflegen |
DSGVO & Datenhoheit
Bei der Frage der Datenhoheit trennen die beiden Systeme wenig. Beide lassen sich self-hosted betreiben — auf Ihren Servern, in Ihrem Rechenzentrum oder in einer von Ihnen kontrollierten Umgebung. Embeddings, Dokumente und Suchindex verlassen Ihre Infrastruktur nicht, und es fließen keine Daten in eine Dritt-Cloud. Das ist die Grundlage einer DSGVO-konformen Architektur und der Grund, warum wir Vektor-Stores grundsätzlich im eigenen Betrieb empfehlen.
Ein Detail, das früh mitzudenken ist: das Recht auf Löschung. Wenn ein Dokument entfernt wird, müssen auch seine Embeddings und Payloads verschwinden. Beide Systeme unterstützen gezieltes Löschen — bei pgvector als DELETE in der Transaktion, bei Qdrant über die Punkt-API. Entscheidend ist, dass Ihre Pipeline die Löschung zuverlässig auslöst. Die Wahl des Stores ändert daran wenig; sie sollte kein Vorwand sein, das Thema aufzuschieben.
Empfehlung nach Ausgangslage
Es gibt keinen pauschalen Sieger — die richtige Wahl folgt Ihrer Ausgangslage.
- Sie betreiben bereits Postgres, der Bestand ist überschaubar, die Filter sind einfach: pgvector. Ein System weniger, transaktionale Konsistenz, geringster Betriebsaufwand. Für viele interne Wissensassistenten ist das die vernünftige Erstwahl.
- Große oder stark wachsende Bestände, anspruchsvolle Metadaten-Filter, echter Bedarf an Hybrid Search oder horizontaler Skalierung: Qdrant. Die Spezialisierung zahlt sich dort aus, wo die Vektorsuche zur Kernlast wird.
- Sie sind unsicher: Starten Sie mit pgvector und kapseln Sie das Retrieval hinter einer klaren Schnittstelle. So bleibt der Wechsel zu Qdrant später ein überschaubarer Eingriff und keine Neuentwicklung.
Der teuerste Fehler ist nicht die „falsche” Datenbank, sondern eine Retrieval-Schicht, die so fest verdrahtet ist, dass jeder Wechsel weh tut. Behandeln Sie den Vektor-Store als austauschbaren Baustein hinter einer Abstraktion — dann relativiert sich die Entscheidung von selbst.
Fazit
- Qdrant vs. pgvector ist keine Frage der Suchqualität, sondern der betrieblichen Passung und Ihres Skalierungspfads.
- pgvector glänzt durch Einfachheit und die native Nähe zu Postgres; Qdrant durch Filterung, Hybrid Search und horizontale Skalierung — auf Kosten eines zweiten Systems.
- Beide sind self-hosted und damit für datenhoheitssensible, DSGVO-konforme Architekturen geeignet.
- Kapseln Sie das Retrieval, damit die Wahl revidierbar bleibt.
Wenn Sie ein RAG-System planen, das über den Prototyp hinausleben soll — mit Evaluierung, Betrieb und der passenden Vektor-Store-Entscheidung — finden Sie den Rahmen unter RAG-Systeme für Unternehmenswissen.