Pinecone lanserar Pg_pinecone, ett söktillägg med öppen källkod för Postgres

Pinecone släppte den 27 oktober 2026 pg_pinecone, ett Postgres-tillägg med öppen källkod som licensieras under Apache 2.0. Tillägget för in den vektorsökmotor som företaget uppger att det kör i stor skala i de pgvector-kolumner som program redan lagrar. I riktmärken som företaget redovisat var tilläggets inbyggda index för 1 miljon vektorer med 768 dimensioner 136 MB, jämfört med 2,0 GB för HNSW med halfvec och 4,1 GB för vektorer i full storlek.

Lanseringen presenterades i ett inlägg med tillkännagivandet, skrivet av Harshita Daddala och Anthony Mahanna. Enligt inlägget är det vanligaste sättet att köra vektorsökning i Postgres att använda ett grafindex som HNSW. För att bibehålla prestandan kräver ett sådant index allt större mängder minne, tar lång tid att bygga och ger sämre träffsäkerhet vid filtrerad sökning. När en fråga avgränsas till en användare eller en klient kan ett grafindex returnera färre rader än vad frågans LIMIT anger. I stället tillämpar pg_pinecone filtret under sökningen. Enligt Pinecone gör det att även en snäv avgränsning kan ge en fullständig resultatlista, och med standardmotorn lämnar data aldrig Postgres.

Tre motorer bakom ett och samma index

pg_pinecone fungerar med vektorkolumner som redan finns i pgvector. Ett program ansluter till Postgres på samma sätt och skickar samma SQL, till exempel ORDER BY embedding <=> $1 LIMIT 10, medan tabellerna, inklusive de fullständiga vektorerna, ligger kvar där de är och Postgres förblir det auktoritativa lagringssystemet.

Varje tabell använder en av tre motorer. Den inbyggda motorn, som är standard, skapar och söker i sitt index helt i Postgres utan något Pinecone-konto, någon API-nyckel eller några nätverksanrop. pgvector-motorn söker i ett befintligt pgvector-index, HNSW eller IVFFlat. I projektets GitHub-arkiv beskrivs den som lämplig för tabeller som redan har ett pgvector-index och inte använder filtrering. Fjärrmotorn skickar sökningen till ett serverlöst index i Pinecones hanterade tjänst och är avsedd för tabeller som har vuxit ur en enda Postgres-server. Det krävs bara ett anrop till pinecone.set_engine() för att byta motor för en tabell. Frågorna behöver inte ändras, och varje motorbyte kan återställas.

Så söker den inbyggda motorn

Liksom pgvectors HNSW använder den inbyggda motorn en algoritm för ungefärlig närmaste granne-sökning, men ersätter grafen med ett inverterat filindex som grupperar liknande vektorer i kluster. Varje vektor lagras som en kvantiserad RaBitQ-kod, med ungefär en bit per dimension plus några korrigeringsvärden. Metoden tillskrivs Gao och Long i inlägget och presenterades på SIGMOD 2024. Koderna för varje kluster packas ihop, så att en sökning läser några få sammanhängande sidor i stället för att hoppa runt i en graf.

En sökning görs i tre steg: först undersöks de närmaste klustren genom att frågevektorn jämförs med varje klusters centroid; därefter beräknas ett uppskattat avstånd för varje rad utifrån dess RaBitQ-kod, och de bästa kandidaterna väljs ut; slutligen rangordnas kandidaterna på nytt med hjälp av deras fullständiga vektorer från tabellen.

Filtreringen sker som en del av sökningen. Pinecone uppgav att pgvectors HNSW tillämpar filtreringen i efterhand: först hittas de närmaste grannarna och sedan tillämpas WHERE-villkoret. Därför sorteras de flesta kandidater bort vid ett snävt filter, och iterativa genomsökningar fyller på listan på bekostnad av tid och, när relaxed_order används, träffsäkerhet. Den inbyggda motorn lagrar ett värde från filterkolumnen bredvid varje rads kod och räknar antalet rader per värde när indexet byggs. För snäva filter, som standard 3 % av raderna eller färre, filtrerar den först genom att söka igenom alla matchande rader i samtliga kluster och poängsätta var och en med sin fullständiga vektor, så att resultaten blir exakta. För bredare filter använder den filtrering i ett enda steg: den söker i upp till hälften av de närmaste klustren och kontrollerar filtret i varje kluster innan poängsättningen.

Nya poster läggs till i det närmaste klustret och kan sökas fram direkt. Eftersom centroidernas placering inte ändras efter att indexet har byggts rekommenderar inlägget att man kör REINDEX eller aktiverar automatiskt underhåll efter större förändringar, till exempel en massinläsning som fördubblar tabellen, för att balansera om klustren.

Riktmärken som Pinecone redovisat

Pinecone jämförde den inbyggda motorn med pgvectors HNSW-index, med vektorer i full storlek och halfvec, på 1 miljon wiki_dpr-vektorer med 768 dimensioner. Testerna kördes på en AWS r6id.4xlarge-instans med 16 virtuella processorkärnor och 128 GB RAM. Svarstiden för ofiltrerad sökning, byggtiden och indexstorleken mättes i en session med PostgreSQL 17, filtrerad sökning i en annan med PostgreSQL 18 och en konfiguration med begränsat minne i en tredje. Svarstiden redovisas som medianen p50 vid k=10 med en klient. Företaget uppgav att den fullständiga konfigurationen och kommandona för att köra om testerna finns i en README-fil för ett verktyg för riktmärken i arkivet.

För de 1 miljon vektorerna redovisade Pinecone ett inbyggt index på 136 MB, jämfört med 2,0 GB för HNSW med halfvec och 4,1 GB för vektorer i full storlek. Vid ofiltrerad sökning redovisade företaget en svarstid på 1,3 ms vid 0,95 recall, jämfört med 1,7 ms för HNSW med halfvec och 2,7 ms för vektorer i full storlek, samt 2,3 ms vid 0,99 recall, jämfört med 4,7 ms respektive 6,7 ms. Med ett filter som matchade 10 % av raderna uppgav Pinecone att den inbyggda motorn nådde 1,000 recall på 12,3 ms med filtrering i ett enda steg, medan HNSW med iterativa genomsökningar som bäst nådde 0,920 recall på 5,9 ms. Med ett filter på 1 % redovisades 0,981 recall på 8,3 ms. Byggtiden uppgavs vara 45 sekunder för den inbyggda motorn, jämfört med 62 sekunder för HNSW med halfvec och 79 sekunder för vektorer i full storlek.

Tillgänglighet och valfria Pinecone-funktioner

pg_pinecone kräver PostgreSQL 17 eller 18, superanvändarbehörighet och att pgvector är installerat på servern. Det installeras från förbyggda versioner på GitHub eller som avbilden pineconeteam/pg_pinecone på Docker Hub. I README beskrivs den som avbilden pgvector/pgvector med tillägget pg_pinecone, publicerad med en tagg per större Postgres-version, till exempel 0.11.0-pg17. För att köra fjärrmotorn krävs också att tillägget läses in via shared_preload_libraries. Installationen skapar tilläggen vector och pg_pinecone och bygger ett index med anropet pinecone.create_index(). Projektet kan även byggas från källkod med en Rust-verktygskedja och cargo-pgrx 0.19.2.

Med en valfri Pinecone API-nyckel synkroniserar fjärrmotorn inbäddningar till ett Pinecone-index i bakgrunden, medan sökningar fortsätter att köras i Postgres tills kopieringen är klar. Inlägget beskriver ytterligare tre valfria funktioner: embed() anropar Pinecones inferenstjänst för att omvandla text till inbäddningar från SQL, fungerar med både den inbyggda motorn och fjärrmotorn och omfattas av Pinecones kostnadsfria nivå för ett första bygge; BM25-fulltextsökning körs parallellt med vektorsökning i samma tabell, och BM25-, vektor- eller hybridsökningar kan göras från SQL; och rerank() sorterar om de främsta resultaten med Pinecones omrankningsmodeller.

Dokumentationen på docs.pinecone.io tar upp installation, lagringsmotorerna, byte av motor och fulltextsökning, medan kodförrådet dessutom innehåller en SQL-referens, en driftshandbok och en guide för katastrofåterställning. Pinecone beskrev detta som projektets första version, uppgav att företaget underhåller pg_pinecone och granskar varje pull request samt sade att den offentliga färdplanen ska utformas utifrån återkoppling som delas via GitHub-ärenden, Discord-communityn och månatliga öppna frågestunder.