Deine Anwendung läuft bereits stabil auf PostgreSQL. Jetzt soll eine semantische Dokumentensuche dazukommen, und die Embeddings sind schnell berechnet. Brauchst du dafür wirklich einen zusätzlichen Datenbank-Cluster im Infrastruktur-Stack – oder reicht die Erweiterung pgvector in deiner bestehenden Datenbank völlig aus?
Eine Vektordatenbank speichert Embeddings zusammen mit ihren Metadaten und beschleunigt die Nachbarschaftssuche über spezialisierte Indizes wie HNSW. Ob du dafür pgvector direkt in PostgreSQL nutzt, einen dedizierten Dienst wie Qdrant betreibst oder bei kleinen Datenmengen sogar exakt ohne Näherungsindex suchst, entscheidet sich nicht an Marketing-Checklisten, sondern an drei Faktoren: deinem Daten- und Lastprofil, dem Verhalten bei strengen Metadaten-Filtern und dem Preis einer verteilten Datenhaltung.
Eine eigene Vektordatenbank spart dir keinen Architekturfehler – wähle deinen Speicher danach, wo deine Berechtigungsdaten liegen, wie selektiv deine Filter sind und wie viel Synchronisationsaufwand dein Team tragen kann.
Exakte Suche vs. HNSW-Index: Was kostet Geschwindigkeit?
Wenn du einen Vektor in einer Tabelle speicherst, wird die Suche dadurch noch nicht automatisch schnell. Bei einer exakten Suche (Flat Search) berechnet die Datenbank für jede Anfrage die Distanz zu jedem freigegebenen Vektor im Bestand. Bei einigen Tausend Dokumentabschnitten dauert das oft nur wenige Millisekunden und liefert garantiert 100 % der mathematisch nächsten Nachbarn.
Wächst der Bestand auf Hunderttausende oder Millionen Vektoren, wird dieser vollständige Scan zu langsam. Dann kommen (ANN-Algorithmen verzichten auf die Prüfung jedes einzelnen Vektors und durchsuchen stattdessen eine vorberechnete Indexstruktur – das senkt die Abfragezeit drastisch, kann aber einzelne echte Nachbarn übersehen.)-Verfahren (ANN) zum Einsatz. Der heute gängigste Standard ist (Hierarchical Navigable Small World: ein mehrschichtiger Graph-Index, der ähnlich wie ein Schnellstraßennetz erst in groben Sprüngen und dann immer feiner zum gesuchten Zielvektor navigiert.):
- Der Gewinn: Die Suchzeit wächst logarithmisch statt linear mit der Datenmenge.
- Der Preis: Der HNSW-Graph benötigt spürbar zusätzlichen Arbeitsspeicher (RAM), verlangsamt Schreib- und Update-Vorgänge und findet nur noch eine sehr gute Näherung. Wie die pgvector-Dokumentation zu HNSW zeigt, steuerst du über Parameter wie
m(Kanten pro Knoten),ef_construction(Bauqualität) undef_search(Suchbreite zur Laufzeit) direkt den Kompromiss zwischen RAM-Verbrauch, Latenz und Recall.
Architektur-Entscheidung: Wann pgvector, wann Qdrant?
| Ansatz | Größter Architektur-Vorteil | Was du dafür in Kauf nimmst |
|---|---|---|
| Exakter Scan (Flat / ohne ANN) | Kein Index-Build, kein zusätzlicher Graph-RAM, 100 % mathematischer Recall als Referenz | Abfragezeit steigt linear mit der Anzahl der zu prüfenden Vektoren |
PostgreSQL + pgvector | Dokumente, Nutzerrechte (ACLs) und Vektoren liegen transaktionssicher (ACID) in einer einzigen Datenbank | HNSW-Indizes und rechenintensive Vektor-Scans teilen sich CPU und RAM mit deiner normalen OLTP-Datenbanklast |
| Spezialisierter Dienst (z. B. Qdrant) | Auf Vektor-Payloads, gefilterte HNSW-Suche, Quantisierung und horizontale Skalierung optimierte Engine | Zweites Speichersystem im Betrieb: Jede Löschung, Rechteänderung und Dokument-Aktualisierung muss fehlerfrei synchronisiert werden |
Der größte Vorteil von pgvector ist organisatorischer Natur: Wenn deine Zugriffsrechte, Mandanten-IDs und Dokumenttexte ohnehin in PostgreSQL liegen, vermeidest du jede Dual-Write-Synchronisation. Wird ein Dokument gelöscht oder eine Berechtigung entzogen, ist der Vektor in derselben Transaktion verschwunden. Ein dedizierter Dienst wie Qdrant spielt seine Stärken aus, wenn die Vektorsuche vom primären Datenbank-Workload entkoppelt werden muss, sehr große Bestände mit Quantisierung im RAM gehalten werden sollen oder komplexe Hybrid-Pipelines direkt in der Such-Engine laufen.
Die unterschätzte Falle: ANN-Suche trifft auf strenge Filter
In unserem deutschen Support-Datensatz darf die öffentliche Suche für Version 2 weder das veraltete v1-Dokument noch die interne Admin-Anleitung zurückgeben. In echten Mehr-Mandanten-Systemen schrumpft ein Filter wie tenant_id = 42 AND version = 2 den erlaubten Suchraum oft auf weniger als 1 % aller gespeicherten Vektoren zusammen.
Genau hier stolpern viele Naive-Implementierungen über das Zusammenspiel von HNSW-Graph und Filterung:
- Post-Filtering nach festem Index-Scan: Sucht der Index zuerst global die 10 nächsten Nachbarn und wirft danach alle Treffer weg, die zum falschen Mandanten gehören, bleiben im schlimmsten Fall null Ergebnisse übrig – obwohl der Mandant passende Dokumente besitzt.
- Iterative Scans & Filterable HNSW: Ab
pgvector 0.8.0lassen sich deshalb iterative Index-Scans aktivieren, die im HNSW-Graphen automatisch weitersuchen, bis genügend erlaubte Zeilen gefunden sind. Qdrant wiederum verknüpft Payload-Indizes direkt mit dem Graph-Traversal (Filterable HNSW), sodass der Suchpfad auch bei hoher Filterselektivität nicht abreißt.
Für die nackten Float32-Vektoren gilt zwar Anzahl × Dimensionen × 4 Byte (1 Million Vektoren à 768 Dimensionen ≈ 3 GB). In der Praxis belegen HNSW-Graphkanten, Payload-Indizes, Datenbank-Overhead und OS-Page-Cache jedoch leicht das 1,5- bis 2,5-Fache dieses Werts im Arbeitsspeicher.
Wie misst du beide Optionen fair gegeneinander?
Bevor du dich für oder gegen ein System entscheidest, führe auf deinen eigenen Vektoren und deinen echten Filtern zwei klar getrennte Messungen durch:
- Index-Recall vs. Exakte Suche: Wie viele der mathematischen Top-10-Nachbarn (aus einem exakten Referenzlauf mit denselben Filtern) findet dein HNSW-Index bei deiner gewählten
ef_search-Einstellung noch? - Fachliche Relevanz gegen Ground Truth: Beantworten die gefundenen Dokumente überhaupt die Nutzerfrage? (Ein perfekter HNSW-Index liefert dir auch mit einem schlechten Embedding-Modell nur irrelevante Nachbarn schneller.)
- Benchmarke Abfragelatenz (p95) immer mit aktivierten Mandanten- und Versionsfiltern.
- Teste gleichzeitig laufende Schreib-, Update- und Löschoperationen während der Suche.
- Halte für Modell-Upgrades einen Blue-Green-Umschaltpfad über eine zweite Tabelle oder Collection bereit.
- Einen HNSW-Index ohne
WHERE-Klausel testen und annehmen, dass er mit strengen Rollenfiltern genauso viele Treffer liefert. - Eine zweite Datenbank einführen, ohne den Sync-Pfad für Dokumentlöschungen und Rechteentzug abzusichern.
- RAM-Bedarf nur über die reine Vektorgröße kalkulieren.
Checkliste für deine Speicher-Architektur
- Exakter Referenzlauf und HNSW-Index liefern unter denselben Zugriffs- und Versionsfiltern eine geprüfte Mindest-Übereinstimmung (ANN-Recall).
- Löschungen und Berechtigungsänderungen in der Primärdatenbank wirken sich ohne gefährliche Verzögerung auf den Suchindex aus.
- Die RAM-Kalkulation berücksichtigt neben den Rohvektoren auch den HNSW-Graphen, Metadaten-Indizes und das Wachstum der nächsten 12 Monate.
- Bei einem Wechsel des Embedding-Modells können alter und neuer Index parallel aufgebaut und atomar umgeschaltet werden.
Quellen und nächste Schritte
- pgvector Repository & Dokumentation (GitHub) – offizielle Referenz zu HNSW, IVFFlat und iterativen Filter-Scans ab Version 0.8.0.
- Qdrant Documentation: Filtering – technische Erklärung zu Payload-Indizes und gefilterter Graph-Suche.
Welches Modell die Vektoren erzeugt, die du hier speicherst, klärt der Leitfaden zu Embedding-Modellen. Wie du anschließend trennst, ob ein Fehlverhalten am HNSW-Index oder an der Semantik des Modells liegt, zeigt Retrieval-Evaluation.