Tech Teardown 025｜pg_vectorsearch: Timescales offizieller neuer Index für Vektorsuche, 100 Millionen Vektoren in 6 Millisekunden

Am 13. Oktober hat Timescale (der nun Tiger Data genannt wird) auf GitHub den neuen Repository pg_vectorsearch offengelegt, eine Erweiterung für die近似 Nearest Neighbor-Suche in PostgreSQL, deren Kern der selbstentwickelte PRISM-Index ist. Am nächsten Tag wurde es auf Hacker News veröffentlicht und löste Diskussionen aus – etwa 200 Likes und 50 Kommentare. Die Popularität rührt von drei Faktoren her: Der Hersteller ist das etablierte PostgreSQL-Team, das bereits TimescaleDB entwickelt hat; die Zahlen, die der offizielle Blog anführt, sind ziemlich ambitioniert (100 Millionen Vektoren, 95% Recall, P50-Latenzzeit von 6 Millisekunden, während der vergleichbare HNSW auf denselben Maschinen keinen Index erstellen kann); sowie die Wahl einer technischen Strategie, die sich von der gängigen Lösung von pgvector unterscheidet: Es wird kein Graphen-Index verwendet, sondern ein Teilungsindex. Aber zunächst ist das wichtigste Satz zuerst: Die ursprüngliche Aussage in der README-Tabellenzeile lautet „Meant for testing, not production“ – nur für Tests, nicht für den Einsatz in der Produktion. Dieser Artikel wird wie gewohnt in sechs Abschnitte unterteilt.

1. Was ist es?

pg_vectorsearch ist eine leistungsstarke Erweiterung für die近似 Nearest Neighbor-Suche in PostgreSQL, die eine Indexmethode namens PRISM bereitstellt, deren vollständiger Name Partitioned Routing Index for Similarity Matching ist. Es handelt sich um einen IVF-Index: Der Vektorraum wird nach dem Mittelpunkt in Clustern unterteilt, und bei der Suche werden nur die wenigen Cluster gescannt, die am wahrscheinlichsten zutreffen. Dies gehört zur „Teilungs-Scanning“-Strategie, nicht zur „Graphen-Entlanggang“-Strategie von pgvector mit HNSW. Die Entstehungsgeschichte ist in dem AGENTS.md im Repository beschrieben: Inspiriert von Google’s ScaNN for AlloyDB und Microsoft’s SPANN, wird das Vektorformat den Standards von pgvector verwendet.

Es gibt drei Aspekte, die klar gemacht werden sollten. Erstens ist es eine offizielle Produktion von Timescale; im Jahr 2024 hat dasselbe Team bereits pgvectorscale (DiskANN-Graphen-Index, der vorherige Kommentator behauptete, einer der Autoren zu sein) offengelegt. Dies ist die zweite Bemühung des Teams in der PostgreSQL-Vektor-Suche. Zudem hat das Blogpost deutlich angekündigt, dass pgvectorscale in den Wartungsmodus versetzt wurde und dass die Ressourcen auf den neuen Index konzentriert werden. Zweitens ist es kompatibel mit pgvector, aber nicht ersetzend: Die bereits vorhandenen vector/halfvec-Felder müssen nicht überschrieben oder kopiert werden; man kann direkt einen PRISM-Index darauf erstellen. Abfragen, die mit pgvector-Operatoren geschrieben wurden, funktionieren weiterhin. Es verfügt auch über zwei Typen, vec32/vec16, sodass es unabhängig von pgvector laufen kann. Drittens ist es alpha: Zwischen den vorläufigen Versionen mag es keinen Upgrade-Pfad geben; die offizielle Empfehlung ist, sich auf eine Wiederherstellung der Erweiterung und des Indexes mit einem Drop vorzubereiten.

Zusammenfassung in einem Satz: Es handelt sich um einen Teilungs-Vektor-Index mit „null Migrationskosten“ für Testzwecke. Die Strategie ist ambitioniert, die Engineering-Reife ist jedoch noch früh.

2. Repository-Struktur

Zuerst korrigiere ich einen kleinen Fehler: Die Sprachmarkierung von GitHub markiert dieses Repository als Rust, obwohl es sich tatsächlich um eine reinen C-Erweiterung handelt. Im Verzeichnis src befindet sich in Zeile 44006 ein .c-Datei, insgesamt 62575 .c-Dateien und 13303 .h-Dateien im gesamten Repository (Repositories-Übersicht). Die Lizenz ist eine lockere PostgreSQL-Lizenz, die Build-Anforderungen sind PostgreSQL 18+ oder höher, GCC 11 oder Clang 14 oder höher sowie das Build-System Meson. Als optional kann CBLAS-Fehlerverzehr durch RaBitQ-Encoding genutzt werden.

Die Modulaufteilung in src entspricht sehr klar der Algorithmenarchitektur: Algo beinhaltet Clustering und Distanzberechnungen, index beinhaltet die Erstellung und Suche nach Indexen, quant beinhaltet Quantisierung, pg beinhaltet die PostgreSQL-Klebe-Schicht, und standalone beinhaltet unabhängige Engine. In Algo finden sich drei Varianten von kmeans (lloyd, elkan, hamerly) sowie die hkmeans-Hierarchie-Clustering-Methode. Clustering ist eine Kernaufgabe bei der Erstellung von Indexen, und die drei Algorithmen sind für unterschiedliche Datenmengen geeignet. In quant gibt es zwei Implementierungen: rabitq und fastscan, jeweils mit drei SIMD-Versionen für avx2, avx512 und neon. In index befinden sich Dateien wie centroid_build, centroid_search, posting_build, posting_scan und posting_split, die die Lesefähigkeiten der Datenstrukturen „Centroidbaum“ und „Inverted Index“ sehr klar trennen.

Eine weitere bemerkenswerte Strukturmerkmal ist die mitgelieferte AI-Unterstützung beim Entwickeln: Unter .claude/skills befinden sich acht Skill-Dateien wie build-feature, create-pr, git-workflow, profiling, release, review, security-review und testing. Zusätzlich gibt es AGENTS.md und CLAUDE.md, die zeigen, dass dieses Projekt nach dem Claude Code-Workshop entwickelt wird. Der Autor hat nicht ausdrücklich gesagt, ob der Code von einer AI erstellt wurde, hier wird lediglich die Tatsache festgestellt, dass das Repository diese Konfiguration enthält. Eine offizielle C-Erweiterung hat die Agent-Workshop-Konfiguration direkt ins Repository gelegt; diese Projektarbeit ist an sich wertvoller als der Codeinhalt für Beobachtungen.

III. Mechanismusanalyse

Der Abfrageweg von PRISM besteht aus fünf Schritten: Zuerst wird das Hierarchie-Centroidbaum genutzt, um die nächsten Clustern zu finden (das Baumdatenvolumen befindet sich im buffer cache), anschließend werden die posting Listen dieser Clustern gescannt, um Kandidaten (asynchrone I/O) zu erhalten. Danach wird RaBitQ verwendet, um eine zweistufige Filterung durchzuführen, und schließlich werden die Überlebenden mit den vollständig geprägten Vektoren in der Warteschlange neu angeordnet, um k Nächstgelegenen zu zurückgeben.

Die drei technischen Säulen werden einzeln analysiert. Erstens ist es die Teilung des Speicherplatzes: Der Vektorraum wird von kmeans in Clustern zusammengefasst, die Clustern werden zu einem oberflächlichen Centroidbaum organisiert. Bei der Abfrage wird von oben nach unten verarbeitet, nur ein kleiner Teil des Speicherplatzes wird berührt. Dies ist dem Konzept von IVFFlat ähnlich, der Unterschied liegt darin, dass die Baumverarbeitung die Prozedur „Welche Clustern gescannt werden“ auch beschleunigt. In Blogartikeln wird auch erwähnt, dass PRISM eine SOAR-Überlauftechnologie implementiert hat, die dem ScaNN ähnelt: Die Grenzvektoren werden gleichzeitig in den nächsten zweiten Cluster gespeichert, wobei etwas Speicherplatz gegen Recall eingetauscht wird.

Zweitens ist RaBitQ Quantization, ein Beitrag aus dem SIGMOD 2024-Paper. Der Vorteil liegt in der binären Quantierung mit theoretischer Fehlergrenze. Jeder quantisierte Vektor hat eine eigene Fehlerrange. Bei der Suche wird zunächst die geschätzte Entfernung berechnet, anschließend werden Vektoren, die „nicht in die Top k gehören“, direkt ausgeschlossen. Nur die wenigen verbleibenden Kandidaten müssen wieder in die Datenbank eingetragen und vollständig sortiert werden. Die Fehlergrenze ist eine mathematische Sicherheit und nicht eine empirische Schwellenwert, was der wesentliche Unterschied zu herkömmlichen binären Quantisierungslösungen ist. Die Seitenlayouts des Posting Listes wurden ebenfalls speziell für die SIMD-Distanzenberechnung entwickelt.

Drittens ist die Integration von SIMD und Engineering: Das Distanzkomplex wird jeweils über die drei Instruction-Sets AVX2, AVX512 und NEON implementiert. Derselbe Kerncode wird sowohl in die PostgreSQL-Erweiterung als auch in den standalone-Engine eingebettet, um die Datenbank-Bottlenecks getrennt voneinander testen zu können. Der Zentrumstamm verläuft über den gemeinsamen Buffer-Cache von PostgreSQL, während die Vektordaten über das Festplattenspeicher-System übertragen werden. MVCC und Flusstransport sind beide im Designziel enthalten.

Die Parameteränderungen sind absichtlich auf ein Minimum reduziert: Auf der Abfrageseite gibt es nur einen prism.nprobe (Anzahl der gescannten Clusters). Der Standardwert 0 bedeutet automatische Wahl des Werts, mit einer Recall von etwa 95%. Um die Recall zu erhöhen, muss der Wert vergrößert werden, um die Geschwindigkeit zu erhöhen, muss der Wert verkleinert werden. Bei Updates werden die Vektoren in den Posting Liste eingefügt, die auf den Routen getroffen haben. Die Liste wird nur erweitert und nicht automatisch geteilt. Die offizielle Prozedur prism_rebalance ermöglicht eine manuelle Trennung übermäßig großer Partitionen oder eine direkte REINDEX für eine Neubildung.

Vier, Zahlen und Verifizierung

Die folgenden Benchmark-Zahlen stammen aus dem offiziellen Blog von Tiger Data (2026-10-13). Es handelt sich um offizielle Angaben und es gibt keine unabhängigen Wiederholungsprüfungen durch Dritte. Bitte berücksichtigen Sie diese Einschränkung bei der Übernahme dieser Zahlen.

Großes Szenario: 100 Millionen Cohere-Vektoren, Vergleich zwischen zwei AWS-Instanzen: r8i.4xlarge (16 vCPU/128 GiB RAM) und r8i.16xlarge (64 vCPU/512 GiB, teurer als der aktuelle Preis um das Vierfache). PRISM benötigt 1 Stunde und 40 Minuten, um einen Index auf einer kleinen Maschine zu erstellen, mit einer Recall von 95% bei einer P50-Zeit von 6 Millisekunden und 21 Millisekunden bei 99% Recall. HNSW kann auf dieser Maschine überhaupt keinen Index erstellen. Bei einer größeren Maschine (512 GiB) dauert es 42 Stunden, um einen Index zu erstellen, mit einer recall von 95% bei 8 Millisekunden, aber 99% recall reicht nicht aus, um eine verfügbare Zeit zu erreichen. Auf derselben Maschine dauert es 49 Minuten, um einen Index mit PRISM zu erstellen, mit einer P50-Zeit von 4 Millisekunden (95%) und 19 Millisekunden (99%). Die offiziellen Tests haben auch gezeigt, dass der auf einer großen Maschine erstellte HNSW-Index bei Abfragen auf einer kleinen Maschine mehr als eine Sekunde dauert, wenn die recall von 95%. Die Schlussfolgerung ist, dass HNSW auf dieser Skala auch nicht ohne große Speicherkapazität funktioniert.

Kleine Szenarien: 1 Million Vektoren, PRISM erreicht 99% Recall und eine Verzögerung von 15 Millisekunden auf einer Maschine mit 2 GiB RAM unter c8g.medium; HNSW benötigt eine doppelt so große Speicherkapazität, die Verzögerung beträgt 392 Millisekunden – mehr als das 23-fache der offiziellen Angaben. Die Indexierung dauert auf einer Maschine mit 4 GiB RAM etwa 3 Minuten, bei HNSW etwa 21,7 Stunden (die Grafiken können während des Erstellungsprozesses nicht in den Speicher eingebaut werden, was zu störenden Effekten führt). Die offizielle Basisangabe besagt außerdem: HNSW verwendet 16-Bit-Halfvec von pgvector, was laut den Offiziellen der beste Kompromiss in ihren Tests mit HNSW ist.

Die offiziellen Schwächen sind in der CHANGELOG in der Kategorie „Known issues“ aufgeführt: Häufige Eingaben führen zu einer Schwankung des Recall-Werts, die Partitionen werden nicht automatisch neu gesplittet, es ist notwendig, prism_rebalance oder REINDEX manuell durchzuführen – die Offiziellen planen, dies in Zukunft automatisch zu machen; der maximale Indexdurchmesser beträgt 1968; Löschvorgänge führen nur zu einer „Grabstein“-Erstellung ohne Rückgabe des Index-Speicherplatzes; Abfragen mit WHERE-Filterungen können weniger als LIMIT-Einträge zurückgeben, die Suche kehrt nicht zurück, um weitere Kandidaten zu suchen (also nur nach dem letzten Filter); wenn der LIMIT-Wert den zulässigen work_mem-Budget überschreitet, wird die Abfrage stillgestellt. In den Kommentaren zu HNSW wird auch das Problem des nachträglichen Filters hinterfragt; ein Kommentator fragte, wie solche Indizes in Szenarien mit mehreren Nutzern und Berechtigungsisolierung verwendet werden können, die Offiziellen haben keine direkte Antwort gegeben; ein Kommentator stellte bei seinen ersten Tests ebenfalls den maximalen Indexdurchmesser fest.

Fünftes Kapitel: Beurteilung

Drei Punkte sollten beachtet werden.

Erstens ist die Wahl der Richtlinie wichtiger als Zahlen. HNSW war in den letzten Jahren die Standardlösung für Vektorabfragen; Google’s ScaNN, Microsoft’s SPANN und die neueren Engine von turbopuffer haben sich auf „Partitionierung + Quantisierung + SIMD-Scanning“ umgestellt, da sequenzielle Speicherabfrage für moderne CPUs günstiger ist als zufällige Zugriffe auf Daten. PRISM ist der neueste Schritt dieser Richtlinie in der PostgreSQL-Ökologie. Selbst wenn die offiziellen Zahlen halbiert werden, bleibt der strukturelle Vorteil, dass „kleine Speichermaschinen große Indizes bedienen können“, unerreichbar für Graph-Indizes: Die Daten von HNSW müssen größtenteils im Speicher gespeichert werden, während die Quantisierte posting Liste von PRISM sicher auf der Festplatte gelagert und nach Bedarf abgerufen werden kann.

Zweitens ist die Kompatibilität mit pgevector eine kluge Umsetzungsstrategie. Es wird den Nutzern nicht gezwungen, Tabellen, Abfragen oder Operatoren zu ändern; durch das Erstellen eines weiteren Indexes auf bestehenden Spalten können Vergleichstests durchgeführt werden, wobei die Kosten für Fehler fast null sind. Das beantwortet auch die Frage „Wird es pgevector ersetzen?“: Nein, es ist eher ein austauschbarer Index-Server in der pgevector-Ökologie. In den Kommentaren fragte jemand, warum man nicht direkt eine PR für pgevector einreicht; die Offiziellen haben keine Antwort gegeben. Aus der Umstellung von pgevectorscale auf den Wartungsmodus geht hervor, dass Timescale ein unabhängiges Produkt wollen möchte, das die Iterationsgeschwindigkeit selbst kontrolliert.

Drittens sind die Schwächen von Alpha real, nicht nur eine bescheidene Versionnummer. Für Multi-Nutzer-SaaS-Lösungen bedeutet nur das nachträgliche Filtering, dass „zuerst eine Menge Kandidaten gescannt werden, die nicht zu diesem Nutzer gehören, bevor sie weggeworfen werden“. Je strenger die Filterbedingungen sind, desto schlechter ist die Effizienz – das wird in der CHANGELOG anerkannt, in den Kommentaren hinterfragt und von den Offiziellen noch nicht gelöst. Der maximale Indexdurchmesser von 1968 schließt einige hohe-Dimensionen-Modelle aus; im Szenario mit churn muss man manuell auf die Rebalance achten, was eine echte Wartungsbelastung darstellt. Diese Punkte zusammen mit der Aussage „Vorveröffentlichungen könnten nicht flüssig aktualisiert werden“ bilden eine vollständige Liste unvollständiger Aspekte.

Ein weiterer Engineering-Blick: Die offizielle C-Extension-Repository enthält eine vollständige Claude Code-Flowkonfiguration (acht Skill-Dateien plus AGENTS.md), was zeigt, dass AI-Assisted-Entwicklung bereits in traditionell konservativen Bereichen wie der Entwicklung von Datenbankkernen eingeführt wurde. Die Qualität des Codes wird letztendlich durch Testergebnisse beurteilt, aber die Handlung, die Konfiguration in das Repository zu integrieren, sollte jede Infrastruktur-Team betrachten.

Sechstes Kapitel: Wer kann es nutzen und wie?

Geeignet für Teams mit einer Vektorgröße von zehn bis hundert Millionen, die unter der Last des HNSW-Memories leiden und in PostgreSQL bleiben wollen (um Geschäftsdaten zu join und Einzeltransaktionen zu aktualisieren), sowie Teams, die das Risiko von Alpha akzeptieren. Diejenigen, die bereits pgvector verwenden, haben den Vorteil: Nachdem man CREATE EXTENSION pg_vectorsearch erstellt hat, kann man direkt auf der bestehenden Vektorkolonne CREATE INDEX … USING prism erstellen. Durch einen EXPLAIN-Test kann man überprüfen, dass der Abfrageplan den neuen Index verwendet. Nach einer Weile des gemeinsamen Gebrauchs der beiden Indizes kann man HNSW entfernen, wenn man zufrieden ist. Die entsprechenden Beziehungen für Operatoren sind vector_l2_ops gegen vec32_l2_ops, halfvec gegen vec16, und die drei Distanzen L2, Innerproduct und Kosinus werden unterstützt.

Die Optimierung ist einfach: prism.nprobe zielt standardmäßig auf etwa 95% Recall ab. Für höhere Recall muss man den Wert erhöhen, für geringere Verzögerung muss man ihn verringern. In Datenbanken mit häufigen Einträgen sollte prism_rebalance in den Betriebsplan aufgenommen werden oder regelmäßig REINDEX durchgeführt werden. Die offizielle Richtlinie empfiehlt nicht, Indizes auf leeren Tabellen zu erstellen, bevor Daten hinzugefügt werden. Bei häufigen Löschvorgängen sollte man beachten, dass der Indexspeicher nicht automatisch zurückgebildet wird.

Für die Produktionsumgebung gibt es nur einen Rat: Warten Sie auf die Beta-Version. Auf der offiziellen Roadmap sind automatische Rebalancing-, streamweise Filter- und Suchfunktionen (WHERE und ORDER BY kombiniert, um ständig Kandidaten zu erzeugen) sowie intensive Tests zur Stärkung von physikalischen Kopien und Backup-Restaurierungen vorgesehen. Diese Punkte decken genau die aktuell größten Schwachstellen ab. Derzeit ist der sinnvollste Ansatz, mit echten Daten im Testumfeld zu testen und die Ergebnisse auf GitHub zu melden. Im offiziellen Blogtext heißt es: „Wenn Ihre Ergebnisse nicht mit unseren übereinstimmen, stellen Sie ein Issue ein, dann untersuchen wir das.“

Für Entwickler, die es nicht verwenden wollen, ist dieses Repository ebenfalls lesenswert: Unter src/algo finden sich die technischen Implementierungen von drei Varianten von kmeans, unter quant die mit SIMD ausgestatteten drei Kernel des RaBitQ-Codes, sowie in AGENTS.md die vollständigen C-Extension-Entwicklungsstandards. Alles sind praktische Lehrbücher für die Entwicklung von Datenbankkernen.

Quelleninformationen

-仓库与文档：github.com/timescale/pg_vectorsearch’s README, CHANGELOG (0.1.0, 2026-10-13), AGENTS.md, src directory structure and number of lines of code (10-15 repository reviews, counted with find+wc)

• All numbers in benchmark (100 million/1 million vectors, latency, index creation time, machine specifications, halfvec baseline): Tiger Data official blog “Announcing pg_vectorsearch” (tigerdata.com, 2026-10-13), all according to official standards, text marked accordingly
• Known issues (churn drift, maximum 1968 dimensions, post-filtering, no space reclamation, work_mem truncation): CHANGELOG 0.1.0 Known issues original text
• HN discussions (about 200▲/50 comments, doubts about post-filtering, measured dimension limits, author of pgvectorscale appears): HN stories and comment pool, listed on 2026-10-14, comments processed as quoted
• “Inspired by ScaNN/SPANN”, “precursor and maintenance model of pgvectorscale”: AGENTS.md self-description and official blog
• Star counts not taken precisely, text processed according to “official new release/days since release”