Ein RAG-Wissenssystem auf eigener Infrastruktur aufbauen lassen? WZ-IT baut und betreibt RAG-Systeme - inklusive der passenden Vektordatenbank, Retrieval-Logik und Berechtigungen, DSGVO-konform aus einer Hand. Internen Assistenten ansehen
Jedes RAG-System braucht eine Vektordatenbank, um das Wissen aus Dokumenten durchsuchbar zu machen. Zwei Optionen dominieren im Open-Source-Umfeld: die Postgres-Erweiterung pgvector und die dedizierte Vektordatenbank Qdrant. Sie stehen für zwei Ansätze - im vertrauten Postgres bleiben oder ein spezialisiertes System betreiben. Dieser Vergleich ordnet beide ein. Stand Oktober 2026.
Inhaltsverzeichnis
- Dedizierte Vektordatenbank oder Postgres-Erweiterung
- pgvector: im Postgres bleiben
- Qdrant: gebaut für Vektorsuche
- Die beiden im Vergleich
- Welche für welchen Fall
Dedizierte Vektordatenbank oder Postgres-Erweiterung
Die Grundsatzfrage ist nicht „welches Tool ist besser", sondern „eigenes System oder bestehende Datenbank erweitern". pgvector bringt die Vektorsuche als Erweiterung in ein vorhandenes PostgreSQL - kein zusätzlicher Dienst, dieselbe Datenbank. Qdrant ist ein eigenständiges, in Rust geschriebenes System, das ausschließlich für die Ähnlichkeitssuche gebaut wurde.
Beide sind Open Source und selbst hostbar. Der Unterschied liegt in Betriebsmodell, Skalierung und darin, wie tief die Vektorsuche mit den übrigen Daten verzahnt ist.
pgvector: im Postgres bleiben
pgvector ist für die meisten ersten RAG-Pipelines der pragmatische Start. Weil es in einer bestehenden Postgres-Datenbank lebt, entfällt der Betrieb eines zusätzlichen Dienstes: Backups, Monitoring, Failover und Zugriffskontrolle laufen über die vorhandene Postgres-Installation.
Der zweite Vorteil ist Konsistenz: Wenn Suchergebnisse und Anwendungsdaten in derselben Datenbank liegen, entfällt eine ganze Klasse von Synchronisationsfehlern. Für typische Größen - grob unter zehn Millionen Vektoren - ist pgvector schnell genug, und mit Erweiterungen wie pgvectorscale (aktuell 0.9.1, mit gehärtetem DiskANN-Index) skaliert es weiter. Wichtig ist die Speicher-Grundlage: Die Suche profitiert stark von schnellen NVMe-SSDs.
Aktuell ist pgvector 0.8.7 vom 1. Oktober 2026. Die Version behebt einen Buffer Overflow beim Aufbau von IVFFlat-Indizes (Changelog). Wer IVFFlat nutzt, sollte das Update zeitnah einspielen.
Qdrant: gebaut für Vektorsuche
Qdrant ist von Grund auf für die Vektorsuche optimiert. Die Rust-Implementierung nutzt SIMD-beschleunigte Distanzberechnungen, speicherabgebildete Ablage und eine Such-Engine, die auf Nearest-Neighbor-Abfragen zugeschnitten ist. In Benchmarks zieht Qdrant bei großen Vektormengen (ab etwa zehn Millionen) und hoher Abfrage-Parallelität davon. Nach unserer Einschätzung ist es in diesen Szenarien im Self-Hosting meist die wirtschaftlichere Wahl, weil weniger Hardware für dieselbe Last nötig ist.
Mit Qdrant 1.19 (aktuell 1.19.2) kamen Funktionen hinzu, die gerade den Speicherbedarf betreffen: TurboQuant speichert Vektoren auf Wunsch nur noch 4-Bit-quantisiert, ohne die Originalvektoren auf der Platte vorzuhalten. Über die Speicherstufen cold, cached und pinned lässt sich je Collection-Komponente festlegen, was im RAM bleibt. Dazu kommen IDF-Statistiken pro Anfrage für die Sparse-Suche, etwa getrennt nach Mandant, und Präfix-Filter auf Keyword-Felder.
Besonders relevant für Wissenssysteme im Unternehmen: Qdrant wendet Payload-Filter direkt während der Ähnlichkeitssuche an (filterbares HNSW). Das ist die Grundlage für berechtigungsgesteuertes RAG, bei dem verbotene Treffer gar nicht erst in die Ergebnismenge gelangen dürfen - siehe RAG mit echten Berechtigungen. Der Preis ist ein eigener Dienst mit eigenem Speicher, Monitoring und Update-Pfad.
Die beiden im Vergleich
| Dimension | pgvector | Qdrant |
|---|---|---|
| Art | PostgreSQL-Erweiterung | Eigenständige Vektordatenbank |
| Betrieb | Teil der bestehenden DB | Separater Dienst (Container/K8s) |
| Konsistenz | Mit Anwendungsdaten in einer DB | Getrenntes System |
| Skalierung | Gut bis ~10 Mio. Vektoren | Stark ab 10 Mio.+ und hoher Parallelität |
| Filter | SQL-Bedingungen | Payload-Filter in der Suche (HNSW) |
| Betriebsaufwand | Nutzt bestehende Postgres-Infrastruktur | Eigener Speicher, Monitoring, Updates |
| Sweet Spot | Erster Einstieg, moderate Größe | Große Skalierung, anspruchsvolle Filter |
Welche für welchen Fall
Die ehrliche Kurzfassung: im Zweifel mit pgvector starten. Wer bereits Postgres nutzt und eine überschaubare Menge an Dokumenten hat, spart sich mit pgvector einen ganzen Dienst und bekommt Konsistenz gratis dazu.
- pgvector, wenn Sie ohnehin Postgres betreiben, die Datenmenge im niedrigen Millionenbereich bleibt und Einfachheit sowie Konsistenz zählen.
- Qdrant, wenn die Vektormenge oder die Abfrage-Parallelität deutlich wächst, oder wenn anspruchsvolle Filter - etwa für Mandantentrennung und Berechtigungen - direkt und schnell in der Suche greifen müssen.
Ein Wechsel bleibt möglich: Die Embeddings sind unabhängig von der Speicher-Engine, der Bestand lässt sich neu in Qdrant indexieren. Deshalb ist der klügere Weg oft, klein zu starten und erst zu wechseln, wenn die Anforderungen es verlangen. Wie die Vektordatenbank ins Gesamtbild passt, zeigt Was ist RAG?.
