Pinecone veröffentlicht Pg_pinecone, eine quelloffene PostgreSQL-Sucherweiterung

Pinecone hat am 27. Oktober 2026 pg_pinecone veröffentlicht, eine quelloffene PostgreSQL-Erweiterung unter der Apache-2.0-Lizenz. Sie bringt die Vektorsuchmaschine, die das Unternehmen nach eigenen Angaben in großem Maßstab betreibt, in die pgvector-Spalten, in denen Anwendungen ihre Daten bereits speichern. In vom Unternehmen veröffentlichten Benchmarks war der native Index der Erweiterung für 1 Million Vektoren mit 768 Dimensionen 136 MB groß, verglichen mit 2,0 GB für HNSW auf halfvec und 4,1 GB für Vektoren in voller Größe.

Die Veröffentlichung wurde in einem Ankündigungsbeitrag von Harshita Daddala und Anthony Mahanna vorgestellt. Dem Beitrag zufolge wird die Vektorsuche in Postgres üblicherweise mit einem Graphindex wie HNSW umgesetzt. Um die Leistung aufrechtzuerhalten, benötigt dieser zunehmend mehr Speicher, der Aufbau dauert lange und bei gefilterten Suchen nimmt die Genauigkeit ab. Wird eine Abfrage auf einen einzelnen Nutzer oder Mandanten beschränkt, kann ein Graphindex weniger Zeilen zurückgeben, als im LIMIT der Abfrage angegeben sind. pg_pinecone wendet den Filter stattdessen bereits während der Suche an. Laut Pinecone können so auch bei einer engen Einschränkung alle gewünschten Ergebnisse zurückgegeben werden. Bei der standardmäßig verwendeten Engine verlassen die Daten Postgres nicht.

Drei Engines, ein Index

pg_pinecone funktioniert mit Vektorspalten, die bereits in pgvector gespeichert sind. Eine Anwendung stellt die Verbindung zu Postgres auf dieselbe Weise her und sendet dieselben SQL-Abfragen, etwa ORDER BY embedding <=> $1 LIMIT 10. Die Tabellen einschließlich der vollständigen Vektoren bleiben dabei an ihrem Speicherort, und Postgres bleibt das führende System für die Daten.

Jede Tabelle verwendet eine von drei Engines. Die native Engine ist die Standardeinstellung; sie erstellt und durchsucht ihren Index vollständig innerhalb von Postgres, ohne dass ein Pinecone-Konto, ein API-Schlüssel oder Netzwerkaufrufe erforderlich sind. Die pgvector-Engine durchsucht einen vorhandenen pgvector-Index, entweder HNSW oder IVFFlat. Laut GitHub-Repository des Projekts eignet sie sich für Tabellen, die bereits einen pgvector-Index haben und keine Filter verwenden. Die Remote-Engine leitet Suchanfragen an einen serverlosen Index im verwalteten Dienst von Pinecone weiter und ist für Tabellen gedacht, die über die Kapazität eines einzelnen Postgres-Servers hinausgewachsen sind. Der Wechsel einer Tabelle zwischen den Engines erfordert nur einen Aufruf von pinecone.set_engine(); die Abfragen bleiben unverändert, und jeder Wechsel lässt sich rückgängig machen.

So sucht die native Engine

Wie HNSW in pgvector verwendet auch die native Engine einen Algorithmus für approximative nächste Nachbarn. Statt des Graphen kommt jedoch ein invertierter Dateiindex zum Einsatz, der ähnliche Vektoren in Clustern gruppiert. Jeder Vektor wird als quantisierter RaBitQ-Code gespeichert, der etwa ein Bit pro Dimension sowie einige Korrekturwerte umfasst. Dabei kommt ein Verfahren zum Einsatz, das der Beitrag Gao und Long, SIGMOD 2024, zuschreibt. Die Codes jedes Clusters werden zusammengefasst gespeichert. Bei einer Suche werden daher einige zusammenhängende Seiten gelesen, statt sich durch einen Graphen zu bewegen.

Eine Suche läuft in drei Schritten ab: Zunächst werden die nächstgelegenen Cluster ermittelt, indem der Abfragevektor mit dem Schwerpunkt jedes Clusters verglichen wird. Anschließend wird anhand des RaBitQ-Codes für jede Zeile eine geschätzte Distanz berechnet und die besten Kandidaten werden ausgewählt. Zuletzt werden diese Kandidaten anhand ihrer vollständigen Vektoren aus der Tabelle neu bewertet.

Die Filterung erfolgt direkt während der Suche. Laut Pinecone wendet HNSW in pgvector Filter nachträglich an: Zuerst werden die nächsten Nachbarn gefunden, danach wird die WHERE-Klausel angewendet. Bei einem engen Filter wird dadurch der Großteil der Kandidaten verworfen, und iterative Scans füllen die Ergebnisliste wieder auf – auf Kosten der Geschwindigkeit und, bei Verwendung von relaxed_order, der Genauigkeit. Die native Engine speichert neben dem Code jeder Zeile den Wert der Filterspalte und zählt beim Erstellen des Indexes die Zeilen für jeden Wert. Bei engen Filtern, standardmäßig bei 3 % der Zeilen oder weniger, filtert sie vorab: Sie durchsucht alle passenden Zeilen in sämtlichen Clustern und bewertet jede anhand ihres vollständigen Vektors, sodass die Ergebnisse exakt sind. Bei weiter gefassten Filtern verwendet sie eine einstufige Filterung: Sie durchsucht bis zur Hälfte der nächstgelegenen Cluster und prüft den Filter innerhalb jedes Clusters, bevor sie die Bewertung vornimmt.

Neu eingefügte Zeilen werden dem nächstgelegenen Cluster zugeordnet und sind sofort durchsuchbar. Da die Schwerpunkte an den Positionen verbleiben, die ihnen beim Erstellen des Indexes zugewiesen wurden, empfiehlt der Beitrag, nach umfangreichen Änderungen REINDEX auszuführen oder die automatische Wartung zu aktivieren. Das gilt beispielsweise nach einem Massenimport, durch den sich die Größe der Tabelle verdoppelt, damit die Cluster neu ausbalanciert werden.

Von Pinecone veröffentlichte Benchmark-Ergebnisse

Pinecone verglich die native Engine mit dem HNSW-Index von pgvector und verwendete dafür Vektoren in voller Größe sowie halfvec. Als Datengrundlage dienten 1 Million wiki_dpr-Vektoren mit 768 Dimensionen. Die Tests liefen auf einer AWS-Instanz des Typs r6id.4xlarge mit 16 vCPUs und 128 GB RAM. Latenz bei ungefilterten Suchen, Erstellungszeit und Indexgröße wurden in einer Testsitzung unter PostgreSQL 17 gemessen, gefilterte Suchen in einer zweiten unter PostgreSQL 18 und eine Konfiguration mit begrenztem Speicher in einer dritten. Die Latenz wird als Median p50 bei k=10 und einem Client angegeben. Das Unternehmen erklärte, dass die vollständige Einrichtung und die Befehle zur Wiederholung der Tests in der README-Datei eines Benchmark-Harness im Repository zu finden sind.

Für 1 Million Vektoren gab Pinecone eine Größe des nativen Indexes von 136 MB an, verglichen mit 2,0 GB für HNSW auf halfvec und 4,1 GB für Vektoren in voller Größe. Bei ungefilterten Suchen meldete das Unternehmen eine Latenz von 1,3 ms bei einem Recall von 0,95, gegenüber 1,7 ms für HNSW auf halfvec und 2,7 ms für Vektoren in voller Größe. Bei einem Recall von 0,99 betrug die Latenz 2,3 ms, verglichen mit 4,7 ms beziehungsweise 6,7 ms. Bei einem Filter, der auf 10 % der Zeilen zutraf, erreichte die native Engine laut Pinecone mit einstufiger Filterung einen Recall von 1,000 in 12,3 ms. HNSW mit iterativen Scans erreichte dagegen höchstens einen Recall von 0,920 in 5,9 ms. Bei einem Filter von 1 % gab Pinecone einen Recall von 0,981 in 8,3 ms an. Die gemeldete Erstellungszeit betrug 45 Sekunden für die native Engine, verglichen mit 62 Sekunden für HNSW auf halfvec und 79 Sekunden für Vektoren in voller Größe.

Verfügbarkeit und optionale Pinecone-Funktionen

pg_pinecone erfordert PostgreSQL 17 oder 18, Superuser-Zugriff und eine auf dem Server installierte pgvector-Erweiterung. Die Installation erfolgt über vorgefertigte Releases auf GitHub oder als Image pineconeteam/pg_pinecone auf Docker Hub. In der README wird es als pgvector/pgvector-Image mit hinzugefügtem pg_pinecone beschrieben, das mit jeweils einem Tag pro PostgreSQL-Hauptversion veröffentlicht wird, zum Beispiel 0.11.0-pg17. Für den Betrieb der Remote-Engine muss die Erweiterung außerdem über shared_preload_libraries geladen werden. Bei der Einrichtung werden die Erweiterungen vector und pg_pinecone erstellt und mit einem Aufruf von pinecone.create_index() ein Index angelegt. Das Projekt lässt sich mit einer Rust-Toolchain und cargo-pgrx 0.19.2 auch aus dem Quellcode erstellen.

Mit einem optionalen Pinecone-API-Schlüssel synchronisiert die Remote-Engine Embeddings im Hintergrund mit einem Pinecone-Index. Während die Kopie erstellt wird, laufen Suchvorgänge weiterhin in Postgres. Der Beitrag beschreibt drei weitere optionale Funktionen: embed() ruft den Inferenzdienst von Pinecone auf, um Text direkt aus SQL in Embeddings umzuwandeln. Die Funktion unterstützt sowohl die native als auch die Remote-Engine und ist für den ersten Build durch Pinecones kostenlosen Tarif abgedeckt. Die BM25-Volltextsuche läuft parallel zur Vektorsuche in derselben Tabelle; BM25-, Vektor- oder hybride Abfragen lassen sich aus SQL ausführen. Mit rerank() werden die besten Suchergebnisse anhand von Pinecones Reranking-Modellen neu sortiert.

Die Dokumentation auf docs.pinecone.io behandelt die Installation, die Speicher-Engines, den Wechsel zwischen Engines und die Volltextsuche. Das Repository enthält außerdem eine SQL-Referenz, ein Betriebshandbuch und einen Leitfaden zur Notfallwiederherstellung. Pinecone bezeichnete dies als erste Veröffentlichung des Projekts, erklärte, das Unternehmen pflege pg_pinecone und prüfe jeden Pull Request, und kündigte an, die öffentliche Roadmap auf Grundlage von Rückmeldungen aus GitHub-Issues, der Discord-Community und den monatlichen Sprechstunden zu erstellen.