pgvector 0.7 und darüber hinaus: Was sich für Vector Search in Produktion geändert hat

Wenn du dein Vector-Search-Setup auf einem frühen pgvector-Release aufgebaut und seitdem nicht mehr angeschaut hast, verhält sich die Extension, die du heute betreibst, anders. Index-Build-Zeiten sind gesunken, die Query-Genauigkeit unter Last hat sich verbessert, und die Standardwerte, die vor zwei Jahren sinnvoll waren, sind nicht mehr der richtige Ausgangspunkt. Dies ist ein Leitfaden dazu, was sich tatsächlich geändert hat und was zu konfigurieren ist, wenn du 2026 performancekritische pgvector-Workloads auf PostgreSQL betreibst.

Wir arbeiten mit vielen Teams, die produktive RAG-Systeme auf Symfony- und Next.js-Backends bauen, und pgvector-Tuning ist eines der häufigsten Dinge, für die man uns hinzuzieht. Meist wurde der Index einmal mit Standardeinstellungen gebaut und nie wieder angefasst, selbst als die Tabelle auf über eine Million Zeilen wuchs.

HNSW-Parameter: ef_construction und m sind kein "einmal einstellen und vergessen"

HNSW (Hierarchical Navigable Small World) ist inzwischen für die meisten Produktions-Workloads die Standardempfehlung gegenüber IVFFlat, aber die beiden Parameter, die sein Verhalten steuern, ef_construction und m, bleiben viel zu oft auf ihren Standardwerten.

m steuert, wie viele bidirektionale Links jeder Knoten im Graph behält. Höhere Werte verbessern den Recall, erhöhen aber sowohl Indexgröße als auch Build-Zeit. ef_construction steuert, wie gründlich die Suche während des Index-Builds ist, was Build-Zeit gegen die Qualität der Graphstruktur eintauscht. Der Zusammenhang zwischen beiden ist nicht linear: m von 16 auf 32 zu verdoppeln, fügt typischerweise spürbar mehr Speicher-Overhead hinzu als ef_construction von 64 auf 128 zu verdoppeln, für einen ähnlichen Recall-Gewinn.

Ein grober Ausgangspunkt, den wir nützlich fanden: für Tabellen unter fünf Millionen Zeilen mit moderaten Recall-Anforderungen halten sich m = 16 und ef_construction = 64 weiterhin gut. Ab dieser Größe, oder wenn Recall wichtiger ist als Build-Geschwindigkeit, schließt ein Wechsel zu m = 24 und ef_construction = 100 eine spürbare Genauigkeitslücke, ohne die Indexgröße zu verdoppeln. Der einzige Weg, es für die eigenen Daten zu wissen, ist beide Einstellungen gegen die eigene Query-Verteilung zu testen, nicht gegen einen synthetischen Benchmark.

Parallele Index-Builds verändern die Rechnung für große Tabellen

Einen HNSW-Index zu bauen war früher ein Single-Thread-Prozess, was bedeutete, dass das Neuindizieren einer Tabelle mit zehn Millionen Zeilen Stunden dauern konnte. Unterstützung für parallele Index-Builds verändert diese Rechnung: auf einer Maschine mit genug CPU-Kernen sinkt die Build-Zeit deutlich, und die Wanduhrzeit-Kosten dafür, mit verschiedenen m- und ef_construction-Werten zu experimentieren, gehen von "ein Wartungsfenster planen" zu "tagsüber ausführen" über.

Das zählt mehr, als es auf dem Papier klingt. Teams, die eine schlechte Index-Konfiguration früher stehen ließen, weil ein Rebuild zu störend war, können Index-Tuning jetzt als iterativen Prozess behandeln. Wenn du deinen Vector-Index im letzten Jahr nicht neu gebaut hast, ist allein die Unterstützung für parallele Builds ein Grund zu testen, ob eine bessere Konfiguration inzwischen günstig genug ist, um sie zu übernehmen.

Sparse Vectors und Hybrid Search

Dense Embeddings sind gut darin, semantische Ähnlichkeit zu erfassen, aber schwach bei exakten Stichwort-Treffern, was ein echtes Problem für Produktnamen, Fehlercodes oder alles ist, wonach ein Nutzer wortwörtlich suchen könnte. Die Unterstützung für Sparse Vectors in neueren pgvector-Releases macht es praktikabel, dichte und dünne Repräsentationen in derselben Abfrage zu kombinieren, ohne eine separate Suchmaschine anzuflanschen.

Das Muster, das wir empfehlen: eine Dense-Vector-Suche für semantische Relevanz und eine Sparse- (oder Volltext-)Suche für exakte Begriffstreffer laufen lassen, dann die beiden Ergebnismengen mit einem Reciprocal-Rank-Fusion-Schritt in der eigenen Anwendungsschicht kombinieren. Das bringt das meiste von dem, was ein dediziertes Hybrid-Search-Produkt bietet, ohne Elasticsearch oder ein ähnliches System zur Infrastruktur hinzuzufügen, nur um eine Teilmenge der Queries abzudecken.

Die richtige Distanzfunktion wählen

pgvector unterstützt Cosine Distance, L2-Distanz (euklidisch) und Inner Product, und die Wahl ist nicht kosmetisch. Cosine Distance ist der richtige Standard für die meisten Embedding-Modelle, da sie den Winkel zwischen Vektoren misst statt ihre Magnitude, was dazu passt, wie die meisten Embedding-Modelle trainiert werden. L2-Distanz ist angebracht, wenn die Magnitude des Vektors echte Information trägt, was bei Text-Embeddings selten, aber bei manchen Computer-Vision-Anwendungsfällen üblich ist. Inner Product ist am schnellsten zu berechnen und die richtige Wahl, wenn die eigenen Embeddings bereits normalisiert sind, da normalisiertes Inner Product und Cosine Distance dasselbe Ranking erzeugen.

Distanzfunktionen über Abfragen gegen denselben Index hinweg zu mischen, ist eine häufige Quelle für schlechte Ergebnisse, die fälschlich als Modellproblem diagnostiziert wird. Prüfe, was das eigene Embedding-Modell erwartet, bevor der Index-Typ gewählt wird, nicht erst, nachdem auffällt, dass der Recall schlechter ist als er sein sollte.

IVFFlat unter gleichzeitigen Schreibzugriffen

IVFFlat hat weiterhin seinen Platz, vor allem für kleinere Tabellen, bei denen sich die Build-Kosten von HNSW nicht lohnen, aber sein Verhalten unter gleichzeitigen Schreibzugriffen verdient einen genaueren Blick, als die meisten Teams ihm geben. IVFFlat partitioniert Vektoren in Listen basierend auf einem Trainingsschritt, der bei der Index-Erstellung läuft. Starke Schreibaktivität nach diesem Zeitpunkt gleicht diese Listen nicht automatisch neu aus, sodass eine Tabelle, die nach dem Bau des Index wächst oder sich in ihrer Verteilung verschiebt, über Monate hinweg an Recall verlieren kann, ohne Fehler oder Warnung.

Wenn du IVFFlat auf einer Tabelle mit nennenswertem Schreibvolumen betreibst, setz einen periodischen Reindex auf den Wartungsplan, statt anzunehmen, dass der Index dauerhaft genau bleibt. Das ist einer der häufigeren stillen Fehlermodi, die wir in Code-Audits sehen: eine Suchfunktion wird langsam schlechter, während jede tatsächlich überwachte Metrik, wie p99-Latenz, gut aussieht.

Speicher-Overhead: wofür man tatsächlich bezahlt

HNSW-Indizes tragen spürbar mehr Speicher-Overhead als IVFFlat, da jeder Vektor zusätzlich zu den rohen Vektordaten seine Graph-Verbindungen speichern muss. Der Overhead skaliert sowohl mit der Vektordimension als auch mit dem m-Parameter. Für eine Tabelle mit 1536-dimensionalen Embeddings, was man von vielen gängigen Embedding-Modellen erhält, kann der HNSW-Index 60 bis 100 Prozent zusätzlich zur rohen Vektorspeicherung hinzufügen, je nach m-Einstellung. Das sind echte Kosten bei einer großen Tabelle und es lohnt sich, sie in die Kapazitätsplanung einzubeziehen, bevor man sich auf eine Konfiguration festlegt, nicht erst, wenn die Datenbank knapp am Speicherplatz wird.

Eine Benchmark-Methodik, die tatsächlich etwas aussagt

Die meisten öffentlichen pgvector-Benchmarks nutzen synthetische Daten mit einer gleichmäßigen Verteilung und ein Query-Muster, das nicht danach aussieht, wie echte Anwendungen Vektordaten abfragen. Das erzeugt Zahlen, die in einem Blogpost großartig aussehen und für die eigene Workload sehr wenig bedeuten.

Ein Benchmark, dem man vertrauen kann, braucht drei Dinge: die eigenen Daten, oder eine Stichprobe, die ihre reale Verteilung und Clusterbildung bewahrt; Query-Muster aus echten Anwendungslogs statt zufälligen Vektoren; und Hardware, die der Produktionsumgebung entspricht, da HNSW-Performance empfindlich auf verfügbaren Speicher reagiert und darauf, wie viel des Index in den Cache passt. Lauf dasselbe Query-Set gegen ein paar Kandidatenkonfigurationen, miss Recall gegen ein vertrauenswürdiges Ground-Truth-Set, und miss p95- und p99-Latenz unter realistischer gleichzeitiger Last, nicht in einer Single-Thread-Schleife.

Wo das 2026 hinführt

Wenn du auf einer älteren pgvector-Version bist, lohnt sich ein Upgrade und der Wechsel von IVFFlat zu HNSW für fast jeden Produktions-Anwendungsfall, den wir uns zuletzt angeschaut haben. Nutze parallele Index-Builds, um Konfigurationen tatsächlich zu testen statt zu raten, stimme die Distanzfunktion auf das eigene Embedding-Modell ab, und wenn IVFFlat irgendwo noch gebraucht wird, leg einen Reindex-Plan dafür an.

Das ist die Art von Tuning-Arbeit, die sich still auszahlt. Niemand merkt, wenn die Vector-Search-Recall gut ist. Man merkt es, wenn sie es nicht ist, meist direkt nachdem ein Kunde sich beschwert, dass die Suche das offensichtliche Ergebnis nicht mehr findet.

Wenn dein Team ein produktives RAG-System auf PostgreSQL baut oder skaliert und einen zweiten Blick auf die Architektur braucht, deckt unsere Arbeit im Bereich Code Quality Consulting genau diese Art von Performance- und Konfigurationsreview ab. Für Teams, die die umgebende Anwendung von Grund auf bauen, ist Custom Software Development meist der Ausgangspunkt. Melde dich unter hello@wolf-tech.io oder finde mehr von unserer Arbeit auf wolf-tech.io.