Brauche ich eine Vektordatenbank? Der Filter zählt

Am Anfang eines Vorhabens mit Vektorsuche steht fast immer dieselbe Frage: welche Vektordatenbank. Sie ist die falsche erste Frage. Die Entscheidung, an der die Trefferliste hängt, betrifft den Filter, und sie fällt in jedem Produkt gleich.

Dieser Beitrag beantwortet zwei Fragen: Brauchen Sie eine Vektordatenbank? Und woran merken Sie, dass Ihre Suche zu wenig zurückgibt?

Er vergleicht keine Anbieter, er nennt keine Preise, und er misst keine Geschwindigkeit.

Der Fehler meldet sich nicht, er kürzt die Liste

Eine Vektorsuche ohne Index ist exakt.

Sie vergleicht die Anfrage mit jeder Zeile und liefert deshalb genau die nächsten Nachbarn.

Ein Index macht sie schnell und dafür näherungsweise. Die pgvector-Dokumentation hält zum Indexieren fest: Die exakte Suche liefert vollständigen Recall, ein Näherungsindex tauscht Recall gegen Geschwindigkeit („trades some recall for speed“).

Das ist bekannt.

Weniger bekannt ist, was passiert, sobald Sie die Vektorsuche filtern, also ein Mandant, ein Zeitraum oder eine Aktenart dazukommt.

Dazu steht im Abschnitt „Filtering“ ein Satz, der die Sache entscheidet: With approximate indexes, filtering is applied after the index is scanned.

Zuerst sucht der Index, danach wirft die Bedingung weg, was nicht passt.

Die Dokumentation rechnet das an ihrem eigenen Beispiel vor.

Trifft die Bedingung zehn Prozent der Zeilen, bleiben bei einem HNSW-Index mit der Voreinstellung hnsw.ef_search von 40 im Mittel vier Zeilen übrig.

Wer fünf Fundstellen erwartet hat, bekommt vier, und in den Häufigen Fragen steht dazu die passende Überschrift: Why are there less results for a query after adding an HNSW index?

Bemerkenswert ist die Art des Ausfalls.

Es gibt keine Fehlermeldung.

Die Abfrage läuft durch, die Anwendung protokolliert nichts, die Überwachung schlägt nicht an.

Es kommen nur weniger Zeilen zurück als gedacht.

Hängt hinter der Suche ein Sprachmodell, das aus den Fundstellen eine Antwort formuliert, dann klingt diese Antwort souverän und ist trotzdem unvollständig.

Nach unserer Beobachtung aus eigener Projektarbeit wurden die Antworten auffällig, während der Vektorspeicher unbeanstandet lief.

Der Weg zur Ursache führte durch die Abfrage.

Das ist keine Eigenart von pgvector

Qdrant, ein Anbieter genau der Art von Datenbank, um die es in dieser Frage geht, beschreibt dasselbe Problem in eigener Sache.

Nach dessen Darstellung hat man zwei Möglichkeiten, und beide haben einen Preis.

Wer zuerst filtert und dann sucht, zerreißt den Graphen: pre-filtering should not be used over large datasets as it breaks too many links in the HNSW graph, causing lower accuracy.

Wer zuerst sucht und dann filtert, wirft einen großen Teil des Gefundenen wieder weg.

Der Ausweg des Anbieters ist ein Index, der zusätzliche Verbindungen zwischen den übrig gebliebenen Punkten zieht.

Das ist eine Anbieterangabe, und sie ist trotzdem lehrreich, weil selbst der gut gelöste Fall an einer Größe hängt, die im eigenen Bestand steht: an der Zahl der verschiedenen Werte im Filterfeld.

Genau das sagt derselbe Text: Die Wahl zwischen Vorfiltern und dem filterfähigen Index hänge von dieser Zahl ab.

Die Wahl des Produkts nimmt Ihnen diese Entscheidung nicht ab.

Sie verschiebt nur, wer sie ausspricht.

Darunter liegt das Verfahren selbst.

Der Aufsatz, auf dem die verbreiteten Indizes beruhen, nennt die Näherung schon im Titel: approximate nearest neighbor search, also näherungsweise Suche nach nächsten Nachbarn.

Die Abhilfe gibt es seit Oktober 2024, und sie ist aus

Mit der Version 0.8.0 vom 30. Oktober 2024 hat pgvector wiederholte Indexdurchläufe bekommen, im Changelog als Added support for iterative index scans geführt.

Der Index wird dann so lange weiter durchsucht, bis genug Zeilen zusammen sind oder eine Obergrenze erreicht ist.

Zur Wahl stehen zwei Betriebsarten, streng nach Abstand sortiert oder gelockert mit besserem Recall.

Der Schalter ist ab Werk ausgeschaltet.

Im Quellcode der Erweiterung wird hnsw.iterative_scan mit dem Wert off angemeldet.

Voreingestellt bleibt also das Verhalten, das die kurze Liste erzeugt.

Wer nichts tut, bekommt es.

Auch wenn Sie den Schalter umlegen, gilt weiter eine Obergrenze: hnsw.max_scan_tuples steht auf 20.000. Sie kaufen Recall mit Laufzeit.

Diese Abwägung gehört aufgeschrieben.

Vier Wege, und der erste ist gar kein Vektorindex

Die Dokumentation nennt für Abfragen mit Bedingung vier Wege, und der naheliegende kommt ohne Näherung aus: ein gewöhnlicher Index auf der Filterspalte.

Dazu steht dort, exakte Indizes arbeiteten gut bei Bedingungen, die einen kleinen Anteil der Zeilen treffen.

Danach folgen der mehrspaltige Index, der Teilindex für wenige verschiedene Filterwerte und die Partitionierung für viele.

Ein Fall daraus verdient eine eigene Zeile, weil er im B2B-Geschäft ständig vorkommt.

Für mehrere Mandanten in einer Tabelle hält die Dokumentation fest, dass ein gemeinsamer näherungsweiser Index dazu führt, dass die Vektoren des einen Mandanten den Recall des anderen beeinflussen.

Empfohlen werden getrennte Partitionen oder getrennte Tabellen.

Wer Mandantentrennung zugesagt hat, entscheidet diese Frage nicht nach der Suchgüte.

Unsere Faustregel dazu ist kurz: Wer das Feld benennen kann, nach dem gefiltert wird, und weiß, wie viele verschiedene Werte darin stehen, hat die Entscheidung bereits getroffen.

Wer es nicht kann, hat ein Bestandsproblem.

Wie das aussieht, steht in einem eigenen Beitrag: Ohne Nachführung veraltet jede Antwort.

Das Einbettungsmodell entscheidet über den Index

Beide Indexarten von pgvector, HNSW und IVFFlat, nehmen für den Typ vector bis zu 2.000 Dimensionen.

Das ist die Grenze des Typs.

Dazu die Herstellerangabe von OpenAI: Voreingestellt liefert text-embedding-3-small Vektoren mit 1.536 Dimensionen, text-embedding-3-large solche mit 3.072.

Das größere Modell passt in voller Breite in keinen der beiden Indizes.

Auswege gibt es, und sie stehen in denselben Häufigen Fragen: Half Precision (halfvec) bis 4.000 Dimensionen, binäre Quantisierung bis 64.000, das Indexieren von Teilvektoren, oder von vornherein weniger Dimensionen anfordern.

Alle vier sind vertretbar.

Nachträglich ist keiner davon billig: Jeder verlangt, den Bestand noch einmal einzubetten.

Diese Entscheidung gehört vor den ersten Einbettungslauf.

Die Gegenprobe, die Sie ohne uns machen können

Die Dokumentation sagt selbst, wie man den Recall überwacht: Ergebnisse der näherungsweisen Suche mit denen der exakten vergleichen.

Daraus wird ein Vorgehen, das sich am laufenden Bestand ohne Umbau durchführen lässt.

• Nehmen Sie zehn echte Abfragen aus dem Betrieb, mit dem Filter, den die Anwendung tatsächlich setzt.

• Führen Sie jede zweimal aus, einmal normal und einmal als exakte Suche.

• Vergleichen Sie beide Male die Zahl der Zeilen und die Schnittmenge der Kennungen.

Für den zweiten Lauf schalten Sie den Indexscan innerhalb der Transaktion ab:

SET LOCAL enable_indexscan = off;

Kommen dieselben Zeilen zurück, ist Ihr Index in Ordnung, und die Frage nach dem Produkt hat sich für diesen Bestand erledigt.

Fehlen Zeilen, kennen Sie jetzt die Ursache, und die vier Wege oben sind die Antwort darauf.

Wir nehmen keine eigene Vektordatenbank in ein Angebot auf, solange darin nicht auch das Filterfeld und die Zahl seiner verschiedenen Werte stehen.

Wo diese Aussage aufhört zu gelten

Sie gilt für pgvector im Stand vom 24. August 2026 und für Bestände, die in ein PostgreSQL passen, das ohnehin schon läuft und betreut wird.

Läuft keines, fällt die Rechnung anders aus, denn dann steht nicht eine Erweiterung gegen einen Dienst, sondern eine Datenbank gegen eine Datenbank.

Sie gilt auch nicht für die Fälle, für die es die spezialisierten Anbieter gibt.

Ein Filter mit wenigen verschiedenen Werten über einem sehr großen Bestand ist genau der Fall, für den ein filterfähiger Index gebaut wurde.

Wer den hat, hat ein echtes Argument.

Und sie sagt nichts über Durchsatz.

Wir haben die Produkte nicht gegeneinander gemessen.

Die Zahlen in diesem Beitrag sind Voreinstellungen und Grenzen aus den Dokumentationen, keine Messwerte.

Wer eine Zahl zur Geschwindigkeit braucht, erhebt sie an seinem eigenen Bestand, mit seinen eigenen Abfragen.

Ob Sie für die Anwendung über der Suche ein Framework brauchen, ist noch einmal eine andere Frage. Dazu haben wir an anderer Stelle geschrieben: LangChain lohnt sich erst, sobald Zustand im Ablauf steckt.

Quellen

Quellen zuletzt geprüft am 25. August 2026.

• pgvector, Repository auf GitHub, Kurzbeschreibung Open-source vector similarity search for Postgres. Daraus die Abschnitte Indexing, Filtering, Iterative Index Scans, Multitenancy, Performance und die Häufigen Fragen. github.com/pgvector/pgvector

• pgvector: pgvector/CHANGELOG.md at master. Version 0.8.0 vom 30. Oktober 2024 mit „Added support for iterative index scans“, jüngste Version 0.8.6 vom 29. Juli 2026. github.com/pgvector/pgvector, CHANGELOG.md

• pgvector: pgvector/src/hnsw.c at master. Dort wird hnsw.iterative_scan mit dem Anfangswert HNSW_ITERATIVE_SCAN_OFF angemeldet. github.com/pgvector/pgvector, src/hnsw.c

• Qdrant: A Complete Guide to Filtering in Vector Search, 10. September 2024. Anbieterangabe. qdrant.tech, Filtering in Vector Search

• Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs, arXiv:1603.09320, eingereicht am 30. März 2016, zuletzt geändert am 14. August 2018. arxiv.org/abs/1603.09320

• OpenAI: Vector embeddings, Abschnitt zu den Modellen. Daraus die voreingestellten Vektorlängen 1.536 und 3.072 sowie der Übergabewert dimensions. Anbieterangabe. developers.openai.com, Vector embeddings

Nicht durch eine Quelle belegt: die Beobachtung, dass die Antworten auffällig werden, während der Vektorspeicher unbeanstandet läuft, und die Faustregel zum Filterfeld.

Diese Beobachtung stammt aus eigener Projektarbeit; Projekte und Auftraggeber werden nicht benannt.