# Vektordatenbanken – pgvector, Qdrant und die Indexfrage

> **Autor:** Lukas Kopischke (Lead Software-Engineer, Düsseldorf)
> **Kanonische URL:** https://lukiluki.me/garden/vector-databases
> **Markdown-Endpunkt:** https://lukiluki.me/garden/vector-databases.md
> **Kategorie:** KI & Agents | **Tags:** pgvector, Qdrant, HNSW, PostgreSQL
> **Veröffentlicht:** 2026-10-29 | **Aktualisiert:** 2026-11-02
> **Zusammenfassung:** Vektordatenbanken im Architekturvergleich: Wann pgvector in PostgreSQL genügt, wie HNSW-Indizes und Filter zusammenspielen und wann Qdrant sinnvoll ist.

---
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.

> **Merksatz:**
> 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 Approximate Nearest Neighbor (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 HNSW (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](https://github.com/pgvector/pgvector#hnsw) zeigt, steuerst du über Parameter wie `m` (Kanten pro Knoten), `ef_construction` (Bauqualität) und `ef_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](/datasets/retrieval-de.json) 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.0` lassen sich deshalb [iterative Index-Scans](https://github.com/pgvector/pgvector#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](https://qdrant.tech/documentation/concepts/filtering/) (Filterable HNSW), sodass der Suchpfad auch bei hoher Filterselektivität nicht abreißt.

> **Reine Vektor-Formeln unterschlagen den Index-RAM**
> 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:

1. **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?
2. **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.)

  #### Empfohlen (Do): Messen mit realer Filterselektivität & Update-Last
* 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.
  #### Vermeiden (Don't): Ungefilterte synthetische Benchmarks glauben
* 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)](https://github.com/pgvector/pgvector) – offizielle Referenz zu HNSW, IVFFlat und iterativen Filter-Scans ab Version 0.8.0.
- [Qdrant Documentation: Filtering](https://qdrant.tech/documentation/concepts/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](/garden/embedding-models). Wie du anschließend trennst, ob ein Fehlverhalten am HNSW-Index oder an der Semantik des Modells liegt, zeigt [Retrieval-Evaluation](/garden/retrieval-evaluation).

---
*Quelle: [Lukas Kopischke – Digital Garden](https://lukiluki.me/garden/vector-databases) | Vollständiger Index: [llms.txt](https://lukiluki.me/llms.txt)*