Pinecone udostępnia Pg_pinecone — otwartoźródłowe rozszerzenie wyszukiwania dla Postgresa

27 października 2026 r. firma Pinecone udostępniła pg_pinecone — rozszerzenie Postgresa o otwartym kodzie źródłowym, objęte licencją Apache 2.0, które udostępnia kolumnom pgvector, w których aplikacje już przechowują dane, silnik wyszukiwania wektorowego wykorzystywany przez firmę na dużą skalę. Według benchmarków przeprowadzonych przez firmę natywny indeks rozszerzenia dla 1 miliona wektorów o 768 wymiarach zajmował 136 MB, w porównaniu z 2,0 GB w przypadku HNSW dla halfvec i 4,1 GB dla wektorów pełnowymiarowych.

Informację o wydaniu przedstawiono we wpisie ogłaszającym premierę, którego autorami są Harshita Daddala i Anthony Mahanna. Jak podano we wpisie, powszechnym sposobem realizowania wyszukiwania wektorowego w Postgresie jest indeks grafowy, taki jak HNSW. Jego utrzymanie w celu zachowania wydajności wymaga coraz większej ilości pamięci, indeks długo się buduje, a wyszukiwanie z filtrowaniem obniża jego dokładność. Gdy zapytanie ogranicza się do jednego użytkownika lub dzierżawcy, indeks grafowy może zwrócić mniej wierszy, niż określa klauzula LIMIT zapytania. Zamiast tego pg_pinecone stosuje filtr podczas wyszukiwania. Według Pinecone dzięki temu nawet przy wąskim zakresie wyszukiwania można uzyskać pełny zestaw wyników, a dane nie opuszczają Postgresa, jeśli używany jest domyślny silnik.

Trzy silniki obsługujące jeden indeks

pg_pinecone współpracuje z kolumnami wektorowymi, które są już przechowywane w pgvector. Aplikacja łączy się z Postgressem w ten sam sposób i wysyła ten sam kod SQL, na przykład ORDER BY embedding <=> $1 LIMIT 10. Tabele, wraz z pełnymi wektorami, pozostają na miejscu, a Postgres nadal jest systemem ewidencji danych.

Każda tabela korzysta z jednego z trzech silników. Silnik natywny, domyślny, tworzy indeks i przeszukuje go w całości w Postgresie — bez konta Pinecone, klucza API ani połączeń sieciowych. Silnik pgvector przeszukuje istniejący indeks pgvector — HNSW lub IVFFlat. W repozytorium projektu w serwisie GitHub opisano go jako odpowiedni do tabel, które mają już indeks pgvector i nie stosują filtrowania. Silnik zdalny kieruje wyszukiwanie do indeksu bezserwerowego w zarządzanej usłudze Pinecone. Jest przeznaczony do tabel, które przerosły możliwości pojedynczego serwera Postgres. Przełączenie tabeli między silnikami wymaga jednego wywołania pinecone.set_engine(), nie zmienia zapytań, a każdą taką zmianę można cofnąć.

Jak wyszukuje silnik natywny

Podobnie jak HNSW w pgvector, silnik natywny korzysta z algorytmu przybliżonego wyszukiwania najbliższych sąsiadów, ale zamiast grafu używa indeksu pliku odwróconego, który grupuje podobne wektory w klastry. Każdy wektor jest przechowywany jako skwantyzowany kod RaBitQ, zajmujący około jednego bitu na wymiar oraz kilka wartości korygujących. Zastosowano w nim metodę, której autorstwo wpis przypisuje Gao i Longowi (SIGMOD 2024). Kody w każdym klastrze są spakowane razem, dzięki czemu wyszukiwanie odczytuje kilka sąsiadujących stron zamiast przeskakiwać między elementami grafu.

Wyszukiwanie przebiega w trzech krokach: najpierw wybierane są najbliższe klastry przez porównanie wektora zapytania z centroidem każdego klastra; następnie dla każdego wiersza obliczana jest szacunkowa odległość na podstawie jego kodu RaBitQ i pozostają tylko najlepsze kandydatury; na końcu kandydatury są ponownie szeregowane z użyciem pełnych wektorów z tabeli.

Filtrowanie odbywa się w ramach wyszukiwania. Według Pinecone HNSW w pgvector stosuje filtrowanie po wyszukiwaniu: najpierw znajduje najbliższych sąsiadów, a dopiero potem stosuje klauzulę WHERE. W rezultacie wąski filtr odrzuca większość kandydatur, a skanowanie iteracyjne uzupełnia listę kosztem czasu i — gdy używane jest relaxed_order — dokładności. Silnik natywny przechowuje wartość kolumny filtra obok kodu każdego wiersza i podczas tworzenia indeksu zlicza wiersze dla każdej wartości. W przypadku wąskich filtrów — domyślnie obejmujących 3% wierszy lub mniej — najpierw stosuje filtr, skanując wszystkie pasujące wiersze we wszystkich klastrach i oceniając każdy z nich na podstawie pełnego wektora, dzięki czemu wyniki są dokładne. Przy szerszych filtrach wykorzystuje filtrowanie jednoetapowe: przeszukuje do połowy najbliższych klastrów i sprawdza filtr w każdym klastrze przed oceną wektorów.

Nowe rekordy trafiają do najbliższego klastra i od razu można je wyszukiwać. Ponieważ centroidy pozostają w miejscach wyznaczonych podczas tworzenia indeksu, we wpisie zaleca się uruchomienie REINDEX lub włączenie automatycznej konserwacji po dużych zmianach, takich jak masowe wczytanie danych, które podwaja rozmiar tabeli, aby ponownie zrównoważyć klastry.

Benchmarki przedstawione przez Pinecone

Pinecone porównało silnik natywny z indeksem HNSW w pgvector, używając wektorów pełnowymiarowych i halfvec, na 1 milionie wektorów wiki_dpr o 768 wymiarach. Testy przeprowadzono na instancji AWS r6id.4xlarge z 16 vCPU i 128 GB pamięci RAM. Opóźnienie wyszukiwania bez filtrowania, czas budowania indeksu i jego rozmiar zmierzono podczas jednej sesji na PostgreSQL 17; wyszukiwanie z filtrowaniem — podczas drugiej sesji na PostgreSQL 18, a konfigurację z ograniczoną pamięcią — podczas trzeciej. Opóźnienie podano jako medianę p50 dla k=10 przy jednym kliencie. Firma poinformowała, że pełną konfigurację i polecenia umożliwiające ponowne uruchomienie testów zamieszczono w pliku README zestawu testów porównawczych w repozytorium.

Dla 1 miliona wektorów Pinecone podało, że indeks natywny zajmuje 136 MB, w porównaniu z 2,0 GB w przypadku HNSW dla halfvec i 4,1 GB dla wektorów pełnowymiarowych. Przy wyszukiwaniu bez filtrowania firma odnotowała opóźnienie 1,3 ms przy pełności 0,95, wobec 1,7 ms dla HNSW w halfvec i 2,7 ms dla wektorów pełnowymiarowych, a także 2,3 ms przy pełności 0,99, wobec odpowiednio 4,7 ms i 6,7 ms. Przy filtrze pasującym do 10% wierszy Pinecone podało, że silnik natywny osiągnął pełność 1,000 w 12,3 ms przy filtrowaniu jednoetapowym, podczas gdy HNSW ze skanowaniem iteracyjnym osiągnął najwyżej pełność 0,920 w 5,9 ms. Przy filtrze obejmującym 1% wierszy odnotowano pełność 0,981 w 8,3 ms. Zgłoszony czas budowania indeksu wyniósł 45 sekund dla silnika natywnego, 62 sekundy dla HNSW w halfvec i 79 sekund dla wektorów pełnowymiarowych.

Dostępność i opcjonalne funkcje Pinecone

pg_pinecone wymaga PostgreSQL 17 lub 18, dostępu superużytkownika oraz zainstalowanego na serwerze pgvector. Można go zainstalować z gotowych wydań w serwisie GitHub albo jako obraz pineconeteam/pg_pinecone w Docker Hub; zgodnie z opisem w pliku README jest to obraz pgvector/pgvector z dodanym pg_pinecone, publikowany z jednym tagiem dla każdej głównej wersji Postgresa, na przykład 0.11.0-pg17. Uruchomienie zdalnego silnika wymaga również załadowania rozszerzenia za pomocą shared_preload_libraries. Konfiguracja tworzy rozszerzenia vector i pg_pinecone oraz buduje indeks za pomocą wywołania pinecone.create_index(). Projekt można też zbudować ze źródeł, korzystając z łańcucha narzędzi Rust i cargo-pgrx 0.19.2.

Po podaniu opcjonalnego klucza API Pinecone zdalny silnik synchronizuje osadzenia z indeksem Pinecone w tle, a wyszukiwanie w Postgresie działa do czasu zakończenia kopiowania. W artykule opisano trzy dodatkowe, opcjonalne funkcje: wywołanie embed() korzysta z usługi wnioskowania Pinecone, aby przekształcać tekst w osadzenia bezpośrednio z poziomu SQL; działa zarówno z silnikiem natywnym, jak i zdalnym, a przy pierwszym wdrożeniu można z niego korzystać w ramach bezpłatnego planu Pinecone. Wyszukiwanie pełnotekstowe BM25 działa równolegle z wyszukiwaniem wektorowym w tej samej tabeli, a zapytania BM25, wektorowe lub hybrydowe można wykonywać z poziomu SQL. Funkcja rerank() zmienia kolejność najlepszych wyników, korzystając z modeli ponownego porządkowania Pinecone.

Dokumentacja pod adresem docs.pinecone.io obejmuje instalację, silniki przechowywania, przełączanie między silnikami i wyszukiwanie pełnotekstowe. Repozytorium zawiera ponadto dokumentację referencyjną SQL, instrukcję operacyjną dla operatorów oraz przewodnik odzyskiwania po awarii. Pinecone określiło to wydanie jako pierwsze wydanie projektu, poinformowało, że utrzymuje pg_pinecone i przegląda każde żądanie ściągnięcia, a także zapowiedziało, że publiczny plan rozwoju oprze na opiniach przekazywanych za pośrednictwem zgłoszeń w serwisie GitHub, społeczności na Discordzie i comiesięcznych spotkań konsultacyjnych.