Pinecone vydává pg_pinecone, open source rozšíření pro vyhledávání v Postgresu

Společnost Pinecone vydala 27. října 2026 pg_pinecone, open source rozšíření pro Postgres s licencí Apache 2.0, které přináší do sloupců pgvector, kam aplikace již ukládají data, vektorový vyhledávací engine, jenž podle společnosti provozuje ve velkém měřítku. V benchmarcích zveřejněných společností měl nativní index tohoto rozšíření pro 1 milion vektorů s 768 rozměry velikost 136 MB, zatímco HNSW zabíral 2,0 GB při použití halfvec a 4,1 GB u plnorozměrných vektorů.

Vydání bylo představeno v oznamovacím příspěvku, který napsali Harshita Daddala a Anthony Mahanna. Podle příspěvku je běžným způsobem vektorového vyhledávání v Postgresu grafový index, například HNSW, jehož udržování výkonnosti vyžaduje stále více paměti, jeho vytvoření trvá dlouho a při filtrovaném vyhledávání se snižuje přesnost; pokud je dotaz omezen na jednoho uživatele nebo jednoho tenanta, může grafový index vrátit méně řádků, než stanovuje LIMIT dotazu. pg_pinecone místo toho uplatňuje filtr přímo během vyhledávání. Podle Pinecone tak lze i při úzkém rozsahu získat úplnou sadu výsledků a při použití výchozího enginu data nikdy neopustí Postgres.

Tři enginy za jedním indexem

pg_pinecone pracuje se sloupci obsahujícími vektory, které jsou již uloženy v pgvector. Aplikace se připojuje k Postgresu stejným způsobem a odesílá stejné SQL, například ORDER BY embedding <=> $1 LIMIT 10, přičemž tabulky včetně úplných vektorů zůstávají na svém místě a Postgres nadále slouží jako primární zdroj dat.

Každá tabulka používá jeden ze tří enginů. Nativní engine, který je výchozí, vytváří index i vyhledává výhradně v Postgresu, bez účtu Pinecone, klíče API nebo síťových volání. Engine pgvector prohledává existující index pgvector, HNSW nebo IVFFlat, a úložiště projektu na GitHubu jej označuje za vhodný pro tabulky, které již index pgvector mají a nepoužívají filtrování. Vzdálený engine odesílá vyhledávání do bezserverového indexu v řízené službě Pinecone a je určen pro tabulky, které přerostly možnosti jednoho serveru Postgres. Přepnutí tabulky mezi enginy vyžaduje jediné volání funkce pinecone.set_engine(), dotazy se nemění a každé přepnutí lze vrátit zpět.

Jak vyhledává nativní engine

Stejně jako HNSW v pgvector používá nativní engine algoritmus přibližných nejbližších sousedů, místo grafu však využívá index invertovaných souborů, který seskupuje podobné vektory do shluků. Každý vektor je uložen jako kvantizovaný kód RaBitQ, který zabírá přibližně jeden bit na rozměr a několik korekčních hodnot. Příspěvek uvádí, že tato metoda pochází od Gao a Longa a byla představena na konferenci SIGMOD 2024. Kódy jednotlivých shluků jsou uloženy pohromadě, takže vyhledávání čte několik souvislých stránek místo přeskakování po grafu.

Vyhledávání probíhá ve třech krocích: nejprve se vyberou nejbližší shluky porovnáním dotazovacího vektoru s těžištěm každého shluku, poté se pro každý řádek vypočítá odhadovaná vzdálenost na základě jeho kódu RaBitQ a ponechají se nejlepší kandidáti a nakonec se tito kandidáti znovu seřadí s využitím jejich úplných vektorů z tabulky.

Filtrování probíhá přímo během vyhledávání. Pinecone uvedla, že HNSW v pgvectoru používá filtrování až po vyhledání nejbližších sousedů, kdy se teprve následně uplatní klauzule WHERE, takže úzký filtr vyřadí většinu kandidátů a iterativní skenování seznam znovu doplní za cenu delšího času a při použití relaxed_order také nižší přesnosti. Nativní engine ukládá vedle kódu každého řádku hodnotu filtrovacího sloupce a při vytváření indexu počítá počet řádků pro každou hodnotu. U úzkých filtrů, které ve výchozím nastavení odpovídají nejvýše 3 % řádků, se filtr uplatní předem: prohledají se všechny odpovídající řádky napříč všemi shluky a každý se ohodnotí pomocí úplného vektoru, takže výsledky jsou přesné. U širších filtrů engine používá filtrování v jediné fázi: prohledá až polovinu nejbližších shluků a před ohodnocením ověří filtr uvnitř každého z nich.

Nově vložené záznamy se zařadí do nejbližšího shluku a lze je okamžitě vyhledávat. Protože těžiště zůstávají tam, kam je umístilo vytvoření indexu, příspěvek doporučuje po rozsáhlých změnách, například po hromadném načtení dat, které zdvojnásobí velikost tabulky, spustit REINDEX nebo povolit automatickou údržbu, aby se shluky znovu vyvážily.

Benchmarky zveřejněné společností Pinecone

Pinecone porovnala nativní engine s indexem HNSW v pgvectoru při použití plnorozměrných vektorů a halfvec, a to na 1 milionu vektorů wiki_dpr se 768 rozměry. Testy proběhly na instanci AWS r6id.4xlarge se 16 virtuálními procesory a 128 GB RAM. Latence při vyhledávání bez filtrování, doba vytvoření indexu a jeho velikost byly měřeny v jedné relaci na PostgreSQL 17, filtrované vyhledávání v jiné relaci na PostgreSQL 18 a konfigurace s omezenou pamětí ve třetí relaci. Latence je uváděna jako medián p50 při k=10 a jednom klientovi. Společnost uvedla, že úplný popis nastavení a příkazy pro opakování testů jsou k dispozici v souboru README nástroje pro benchmarking v úložišti.

U 1 milionu vektorů Pinecone uvedla velikost nativního indexu 136 MB, oproti 2,0 GB u HNSW s halfvec a 4,1 GB u plnorozměrných vektorů. Při vyhledávání bez filtrování společnost uvedla latenci 1,3 ms při úplnosti vyhledávání (recall) 0,95, oproti 1,7 ms u HNSW s halfvec a 2,7 ms u plnorozměrných vektorů; při úplnosti 0,99 činila latence 2,3 ms, oproti 4,7 ms a 6,7 ms. U filtru odpovídajícího 10 % řádků Pinecone uvedla, že nativní engine dosáhl úplnosti 1,000 za 12,3 ms při filtrování v jediné fázi, zatímco HNSW s iterativním skenováním dosáhlo nejvýše úplnosti 0,920 za 5,9 ms. U filtru odpovídajícího 1 % řádků společnost uvedla úplnost 0,981 za 8,3 ms. Doba vytvoření indexu činila podle zveřejněných údajů 45 sekund u nativního enginu, oproti 62 sekundám u HNSW s halfvec a 79 sekundám u plnorozměrných vektorů.

Dostupnost a volitelné funkce Pinecone

pg_pinecone vyžaduje PostgreSQL 17 nebo 18, přístup superuživatele a server s nainstalovaným pgvector. Lze jej nainstalovat z předem sestavených vydání na GitHubu nebo jako obraz pineconeteam/pg_pinecone na Docker Hubu, který README popisuje jako obraz pgvector/pgvector doplněný o pg_pinecone a publikovaný s jedním štítkem pro každou hlavní verzi Postgresu, například 0.11.0-pg17; ke spuštění vzdáleného enginu je také nutné načíst rozšíření prostřednictvím shared_preload_libraries. Při nastavení se vytvoří rozšíření vector a pg_pinecone a pomocí volání pinecone.create_index() se vytvoří index. Projekt lze také sestavit ze zdrojového kódu pomocí sady nástrojů Rust a cargo-pgrx 0.19.2.

S volitelným klíčem API Pinecone synchronizuje vzdálený engine embeddingy na index Pinecone na pozadí, zatímco vyhledávání až do dokončení kopírování dál probíhá v Postgresu. Příspěvek popisuje tři další volitelné funkce: embed() volá inferenční službu Pinecone, která převádí text na embeddingy přímo z SQL; funguje s nativním i vzdáleným enginem a první sestavení lze pokrýt bezplatnou úrovní Pinecone. Fulltextové vyhledávání BM25 běží souběžně s vektorovým vyhledáváním nad stejnou tabulkou a dotazy BM25, vektorové i hybridní lze zadávat z SQL. Funkce rerank() pak mění pořadí nejlepších výsledků pomocí modelů Pinecone pro přerankování.

Dokumentace na docs.pinecone.io pokrývá instalaci, úložné enginy, přepínání mezi enginy a fulltextové vyhledávání. Repozitář navíc obsahuje referenční příručku k SQL, provozní příručku pro správce a průvodce obnovou po havárii. Pinecone uvedl, že jde o první vydání projektu, že se stará o pg_pinecone a kontroluje každý požadavek na stažení a že veřejný plán vývoje sestaví na základě zpětné vazby sdílené prostřednictvím hlášení na GitHubu, komunity na Discordu a pravidelných měsíčních konzultačních hodin.