Pinecone julkaisee Pg_pineconen, avoimen lähdekoodin PostgreSQL-hakulaajennuksen

Pinecone julkaisi 27. lokakuuta 2026 pg_pineconen, Apache 2.0 -lisenssillä julkaistun avoimen lähdekoodin PostgreSQL-laajennuksen, joka tuo pgvector-sarakkeisiin, joihin sovellukset jo tallentavat vektorinsa, vektorihakukoneen, jota yhtiö kertoo käyttävänsä suuressa mittakaavassa. Yhtiön ilmoittamissa vertailutesteissä laajennuksen natiivi-indeksin koko oli miljoonalle 768-ulotteiselle vektorille 136 MB, kun HNSW-indeksi puolivektoreilla vei 2,0 GB ja täysikokoisilla vektoreilla 4,1 GB.

Julkaisusta kerrottiin ilmoitusjulkaisussa, jonka kirjoittivat Harshita Daddala ja Anthony Mahanna. Julkaisun mukaan tavallisin tapa toteuttaa vektorihaku PostgreSQL:ssä on käyttää graafi-indeksiä, kuten HNSW:tä. Sen suorituskyvyn ylläpitäminen vaatii yhä enemmän muistia, indeksin rakentaminen kestää kauan, ja tarkkuus heikkenee suodatetussa haussa. Kun kysely rajataan koskemaan yhtä käyttäjää tai vuokralaista, graafi-indeksi voi palauttaa vähemmän rivejä kuin kyselyn LIMIT-määritys edellyttää. pg_pinecone puolestaan soveltaa suodatinta haun aikana. Pineconen mukaan näin myös tiukasti rajatusta hausta saadaan täysi tulosjoukko, eikä data oletusarvoista hakukonetta käytettäessä poistu PostgreSQL:stä.

Kolme hakukonetta yhden indeksin taustalla

pg_pinecone toimii pgvectorissa jo olevien vektorisarakkeiden kanssa. Sovellus muodostaa yhteyden PostgreSQL:ään samalla tavalla ja lähettää saman SQL-kyselyn, esimerkiksi ORDER BY embedding <=> $1 LIMIT 10. Taulut vektoreineen pysyvät ennallaan, ja PostgreSQL säilyy tietojen ensisijaisena lähteenä.

Kukin taulu käyttää yhtä kolmesta hakukoneesta. Oletusarvoinen natiivihakukone rakentaa indeksinsä ja suorittaa haut kokonaan PostgreSQL:n sisällä ilman Pinecone-tiliä, API-avainta tai verkkoyhteyksiä. pgvector-hakukone hakee olemassa olevasta pgvector-indeksistä, joka voi olla HNSW tai IVFFlat. Projektin GitHub-arkiston mukaan se sopii tauluille, joissa on jo pgvector-indeksi eikä tietoja suodateta. Etähakukone ohjaa haut Pineconen hallinnoiman palvelun palvelimettomaan indeksiin, ja se on tarkoitettu tauluille, jotka ovat kasvaneet suuremmiksi kuin yhdelle PostgreSQL-palvelimelle mahtuu. Taulun hakukoneen vaihtaminen toiseksi onnistuu yhdellä pinecone.set_engine()-kutsulla. Kyselyihin ei tarvitse tehdä muutoksia, ja jokaisen vaihdon voi perua.

Näin natiivihakukone suorittaa haut

Kuten pgvectorin HNSW, natiivihakukone käyttää likimääräisen lähimmän naapurin algoritmia, mutta graafin sijaan se käyttää käänteistiedostoindeksiä, joka ryhmittelee samankaltaiset vektorit klustereiksi. Kukin vektori tallennetaan kvantisoituna RaBitQ-koodina, jossa on noin yksi bitti ulottuvuutta kohden sekä muutama korjausarvo. Julkaisussa menetelmän ansioksi mainitaan Gao ja Long sekä SIGMOD 2024. Kunkin klusterin koodit pakataan yhteen, joten haku lukee muutamia peräkkäisiä sivuja sen sijaan, että hyppisi graafissa sivulta toiselle.

Haku etenee kolmessa vaiheessa: ensin etsitään lähimmät klusterit vertaamalla kyselyvektoria kunkin klusterin keskipisteeseen, sitten lasketaan kunkin rivin arvioitu etäisyys sen RaBitQ-koodin perusteella ja valitaan parhaat ehdokkaat, minkä jälkeen ehdokkaat järjestetään uudelleen taulusta saatavien täysikokoisten vektorien perusteella.

Suodatus tapahtuu haun aikana. Pineconen mukaan pgvectorin HNSW käyttää jälkisuodatusta: ensin etsitään lähimmät naapurit ja vasta sen jälkeen sovelletaan WHERE-ehtoa. Tiukka suodatus karsii tällöin suurimman osan ehdokkaista, ja iteratiiviset haut täydentävät tuloslistaa ajan kustannuksella sekä relaxed_order-asetusta käytettäessä myös tarkkuuden kustannuksella. Natiivihakukone tallentaa kunkin rivin koodin viereen suodatinsarakkeen arvon ja laskee rivien määrän arvoittain indeksin rakennusvaiheessa. Tiukkojen suodatusten tapauksessa eli oletusarvoisesti silloin, kun suodatus koskee enintään 3 % riveistä, hakukone suodattaa ensin: se käy läpi kaikki ehdot täyttävät rivit kaikissa klustereissa ja pisteyttää jokaisen täysikokoisen vektorinsa perusteella, jolloin tulokset ovat tarkkoja. Laajempien suodatusten yhteydessä se käyttää yksivaiheista suodatusta: hakuun otetaan enintään puolet lähimmistä klustereista, ja suodatus tarkistetaan kussakin klusterissa ennen pisteytystä.

Uudet lisäykset sijoitetaan lähimpään klusteriin, ja niitä voi hakea heti. Koska klusterien keskipisteet pysyvät rakennusvaiheessa määritetyillä paikoillaan, julkaisussa suositellaan REINDEX-komennon suorittamista tai automaattisen ylläpidon käyttöönottoa suurten muutosten jälkeen. Tällainen muutos voi olla esimerkiksi massalataus, joka kaksinkertaistaa taulun koon. Näin klusterit tasapainottuvat uudelleen.

Pineconen ilmoittamat vertailutestitulokset

Pinecone vertasi natiivihakukonetta pgvectorin HNSW-indeksiin täysikokoisilla vektoreilla ja puolivektoreilla käyttäen miljoonaa 768-ulotteista wiki_dpr-vektoria. Testit suoritettiin AWS r6id.4xlarge -instanssissa, jossa oli 16 vCPU:ta ja 128 GB RAM-muistia. Suodattamattoman haun viive, indeksin rakennusaika ja indeksin koko mitattiin samassa istunnossa PostgreSQL 17:llä, suodatettu haku toisessa istunnossa PostgreSQL 18:lla ja muistin enimmäismäärää rajoittava kokoonpano kolmannessa istunnossa. Viive ilmoitetaan mediaanina p50, kun k=10 ja asiakkaita on yksi. Yhtiön mukaan koko testikokoonpano ja testien uudelleen suorittamiseen tarvittavat komennot löytyvät arkiston vertailutestien README-tiedostosta.

Miljoonan vektorin tapauksessa Pinecone ilmoitti natiivihakukoneen indeksin kooksi 136 MB. HNSW-indeksi vei puolivektoreilla 2,0 GB ja täysikokoisilla vektoreilla 4,1 GB. Suodattamattomassa haussa yhtiö ilmoitti viiveeksi 1,3 ms, kun saantitarkkuus oli 0,95; HNSW:n viive oli puolivektoreilla 1,7 ms ja täysikokoisilla vektoreilla 2,7 ms. Kun saantitarkkuus oli 0,99, natiivihakukoneen viive oli 2,3 ms, kun taas HNSW:n vastaavat luvut olivat 4,7 ms ja 6,7 ms. Kun suodatin vastasi 10 %:a riveistä, Pineconen mukaan natiivihakukone saavutti 1,000:n saantitarkkuuden 12,3 ms:ssa yksivaiheisella suodatuksella. HNSW saavutti iteratiivisilla hauilla parhaimmillaan 0,920:n saantitarkkuuden 5,9 ms:ssa. Yhden prosentin suodattimella saantitarkkuudeksi ilmoitettiin 0,981 ja viiveeksi 8,3 ms. Indeksin rakentaminen kesti ilmoituksen mukaan natiivihakukoneella 45 sekuntia, kun HNSW:llä siihen kului puolivektoreilla 62 sekuntia ja täysikokoisilla vektoreilla 79 sekuntia.

Saatavuus ja valinnaiset Pinecone-ominaisuudet

pg_pinecone vaatii PostgreSQL 17:n tai 18:n, pääkäyttäjän käyttöoikeudet sekä palvelimelle asennetun pgvectorin. Sen voi asentaa valmiiksi käännetyistä julkaisuista GitHubista tai Docker Hubissa julkaistuna pineconeteam/pg_pinecone-kuvana. README kuvaa kuvan pgvector/pgvector-kuvaksi, johon pg_pinecone on lisätty. Kuva julkaistaan yhdellä tunnisteella kutakin Postgresin pääversiota kohden, esimerkiksi 0.11.0-pg17. Etämoottorin käyttäminen edellyttää lisäksi, että laajennus ladataan shared_preload_libraries-asetuksen kautta. Käyttöönotossa luodaan vector- ja pg_pinecone-laajennukset ja rakennetaan indeksi pinecone.create_index()-kutsulla. Projektin voi myös kääntää lähdekoodista Rust-työkaluketjulla ja cargo-pgrx 0.19.2:lla.

Valinnaisen Pinecone API -avaimen avulla etämoottori synkronoi upotukset taustalla Pinecone-indeksiin, ja haut jatkuvat Postgresissa, kunnes kopiointi on valmis. Kirjoituksessa esitellään kolme muuta valinnaista ominaisuutta: embed()-kutsu käyttää Pineconen päättelypalvelua tekstin muuntamiseen upotuksiksi SQL:stä käsin, toimii sekä natiivissa että etämoottorissa, ja sen käyttö sisältyy Pineconen maksuttomaan käyttöoikeuteen ensimmäisen koontiversion osalta; BM25-kokotekstihaku toimii vektorihaun rinnalla samassa taulussa, ja BM25-, vektori- tai hybridikyselyjä voi tehdä SQL:stä käsin; rerank() järjestää tärkeimmät tulokset uudelleen Pineconen uudelleenjärjestelymalleilla.

Sivuston docs.pinecone.io dokumentaatio käsittelee asennusta, tallennusmoottoreita, moottorin vaihtamista ja kokotekstihakua. Lisäksi repositorio sisältää SQL-viiteoppaan, ylläpitäjän toimintaohjeen ja palautumisoppaan vakavista häiriötilanteista. Pinecone kuvaili tätä projektin ensimmäiseksi julkaisuksi, kertoi ylläpitävänsä pg_pineconea ja tarkistavansa jokaisen pull requestin sekä sanoi rakentavansa julkisen kehityssuunnitelman GitHub-ongelmissa, Discord-yhteisössään ja kuukausittaisissa avoimissa keskustelutilaisuuksissa saadun palautteen pohjalta.