Pinecone lanserer Pg_pinecone, en søkeutvidelse med åpen kildekode for Postgres

Pinecone lanserte 27. oktober 2026 pg_pinecone, en Postgres-utvidelse med åpen kildekode under Apache 2.0-lisensen. Den bringer vektorsøkemotoren som selskapet sier det kjører i stor skala, til pgvector-kolonnene som applikasjonene allerede lagrer data i. I referansemålinger rapportert av selskapet var den innebygde indeksen i utvidelsen på 136 MB for 1 million vektorer med 768 dimensjoner, mot 2,0 GB for HNSW på halfvec og 4,1 GB for vektorer i full størrelse.

Lanseringen ble presentert i et kunngjøringsinnlegg skrevet av Harshita Daddala og Anthony Mahanna. Ifølge innlegget er den vanlige måten å kjøre vektorsøk i Postgres på å bruke en grafindeks, for eksempel HNSW. En slik indeks krever stadig mer minne for å opprettholde ytelsen, tar lang tid å bygge og gir dårligere nøyaktighet ved filtrerte søk. Når et søk avgrenses til én bruker eller én leietaker, kan en grafindeks returnere færre rader enn søkets LIMIT. pg_pinecone bruker i stedet filteret under søket. Pinecone sier at dette gjør det mulig å returnere et fullt resultatsett selv med et snevert søkeområde, og med standardmotoren forlater dataene aldri Postgres.

Tre motorer bak én indeks

pg_pinecone fungerer med vektorkolonner som allerede er lagret i pgvector. En applikasjon kobler til Postgres på samme måte og sender den samme SQL-en, for eksempel ORDER BY embedding <=> $1 LIMIT 10, mens tabellene, inkludert de fullstendige vektorene, blir værende der de er, og Postgres fortsetter å være systemet som lagrer de autoritative dataene.

Hver tabell bruker én av tre motorer. Den innebygde motoren, som er standard, bygger og søker i indeksen utelukkende i Postgres, uten Pinecone-konto, API-nøkkel eller nettverkskall. pgvector-motoren søker i en eksisterende pgvector-indeks, HNSW eller IVFFlat. Prosjektets GitHub-repositorium beskriver den som egnet for tabeller som allerede har en pgvector-indeks og ikke bruker filtre. Den eksterne motoren sender søk til en serverløs indeks i Pinecones administrerte tjeneste og er beregnet på tabeller som har vokst seg for store for én Postgres-server. Det kreves bare ett kall til pinecone.set_engine() for å bytte motor for en tabell. Spørringene endres ikke, og alle bytter kan reverseres.

Slik søker den innebygde motoren

I likhet med HNSW i pgvector bruker den innebygde motoren en tilnærmet nærmeste nabo-algoritme, men erstatter grafen med en invertert filindeks som grupperer lignende vektorer i klynger. Hver vektor lagres som en kvantisert RaBitQ-kode, med omtrent én bit per dimensjon pluss noen få korreksjonsverdier. Innlegget tilskriver metoden Gao og Long, SIGMOD 2024. Kodene for hver klynge pakkes sammen, slik at et søk leser noen få sammenhengende sider i stedet for å hoppe rundt i en graf.

Et søk kjøres i tre trinn: Først undersøkes de nærmeste klyngene ved å sammenligne søkevektoren med tyngdepunktet i hver klynge. Deretter beregnes en anslått avstand for hver rad ut fra RaBitQ-koden, og de beste kandidatene beholdes. Til slutt rangeres disse kandidatene på nytt ved hjelp av de fullstendige vektorene fra tabellen.

Filtreringen skjer som en del av søket. Pinecone sier at HNSW i pgvector bruker etterfiltrering: Først finner den de nærmeste naboene, og deretter anvender den WHERE-vilkåret. Dermed forkaster et snevert filter de fleste kandidatene, og iterative skanninger fyller opp listen igjen på bekostning av tid og, når relaxed_order brukes, nøyaktighet. Den innebygde motoren lagrer verdien i filterkolonnen ved siden av hver rads kode og teller rader per verdi under byggingen. For snevre filtre, som standard 3 % av radene eller færre, bruker den forhåndsfiltrering: Den skanner alle rader som samsvarer på tvers av alle klynger og beregner en poengsum for hver ved hjelp av den fullstendige vektoren, slik at resultatene blir eksakte. For bredere filtre bruker den filtrering i ett trinn: Den søker i opptil halvparten av de nærmeste klyngene og kontrollerer filteret i hver klynge før poengsummen beregnes.

Nye innsettinger legges til i den nærmeste klyngen og kan søkes opp umiddelbart. Siden tyngdepunktene forblir der byggingen plasserte dem, anbefaler innlegget at man kjører REINDEX eller aktiverer automatisk vedlikehold etter større endringer, for eksempel en masselasting som dobler tabellen, for å balansere klyngene på nytt.

Referansemålinger rapportert av Pinecone

Pinecone sammenlignet den innebygde motoren med pgvector-indeksen HNSW, både med vektorer i full størrelse og med halfvec, på 1 million wiki_dpr-vektorer med 768 dimensjoner. Testene ble kjørt på en AWS r6id.4xlarge-instans med 16 vCPU-er og 128 GB RAM. Ufiltrert responstid, byggetid og indeksstørrelse ble målt i én økt på PostgreSQL 17, filtrert søk i en annen på PostgreSQL 18, og en konfigurasjon med minnebegrensning i en tredje. Responstiden oppgis som median p50 ved k=10 med én klient. Selskapet opplyste at hele oppsettet og kommandoene for å kjøre testene på nytt finnes i en README-fil for et referanseoppsett i repositoriet.

For 1 million vektorer rapporterte Pinecone en innebygd indeks på 136 MB, sammenlignet med 2,0 GB for HNSW på halfvec og 4,1 GB på vektorer i full størrelse. For ufiltrerte søk rapporterte selskapet en responstid på 1,3 ms ved 0,95 recall, mot 1,7 ms for HNSW på halfvec og 2,7 ms på vektorer i full størrelse, samt 2,3 ms ved 0,99 recall, mot henholdsvis 4,7 ms og 6,7 ms. Med et filter som samsvarte med 10 % av radene, rapporterte Pinecone at den innebygde motoren oppnådde 1.000 recall på 12,3 ms med filtrering i ett trinn, mens HNSW med iterative skanninger på det beste oppnådde 0,920 recall på 5,9 ms. Med et filter på 1 % rapporterte selskapet 0,981 recall på 8,3 ms. Byggetiden var ifølge rapporten 45 sekunder for den innebygde motoren, mot 62 sekunder for HNSW på halfvec og 79 sekunder på vektorer i full størrelse.

Tilgjengelighet og valgfrie Pinecone-funksjoner

pg_pinecone krever PostgreSQL 17 eller 18, superbrukertilgang og at pgvector er installert på serveren. Det kan installeres fra forhåndsbygde utgivelser på GitHub eller som avbildningen pineconeteam/pg_pinecone på Docker Hub. I README-en beskrives denne som avbildningen pgvector/pgvector med pg_pinecone lagt til, publisert med én tagg per hovedversjon av Postgres, for eksempel 0.11.0-pg17. Hvis du kjører den eksterne motoren, må utvidelsen også lastes inn via shared_preload_libraries. Oppsettet oppretter utvidelsene vector og pg_pinecone og bygger en indeks med et kall til pinecone.create_index(). Prosjektet kan også bygges fra kildekoden med Rust-verktøykjeden og cargo-pgrx 0.19.2.

Med en valgfri Pinecone API-nøkkel synkroniserer den eksterne motoren innebygginger til en Pinecone-indeks i bakgrunnen, mens søkene fortsetter å kjøre i Postgres til kopieringen er fullført. Innlegget beskriver tre andre valgfrie funksjoner: embed() kaller Pinecones inferenstjeneste for å gjøre tekst om til innebygginger fra SQL, fungerer med både den innebygde og den eksterne motoren og dekkes av Pinecones gratisnivå for en første bygging; fulltekstsøk med BM25 kjøres parallelt med vektorsøk i samme tabell, og BM25-, vektor- eller hybridsøk kan utføres fra SQL; og rerank() sorterer de beste resultatene på nytt ved hjelp av Pinecones omrangeringsmodeller.

Dokumentasjonen på docs.pinecone.io dekker installasjon, lagringsmotorene, bytte mellom motorer og fulltekstsøk. I tillegg inneholder repositoriet en SQL-referanse, en driftsveiledning og en veiledning for katastrofegjenoppretting. Pinecone beskrev dette som prosjektets første utgivelse, sa at selskapet vedlikeholder pg_pinecone og gjennomgår hver pull request, og opplyste at den offentlige veikartplanen skal utarbeides på grunnlag av tilbakemeldinger som deles gjennom GitHub-saker, Discord-fellesskapet og månedlige spørretimer.