Pinecone lancerer Pg_pinecone, en open source-udvidelse til søgning i Postgres

Pinecone udgav den 27. oktober 2026 pg_pinecone, en open source-udvidelse til Postgres under Apache 2.0-licensen. Den bringer den vektorsøgemotor, som virksomheden siger, den bruger i stor skala, til de pgvector-kolonner, som applikationer allerede lagrer. I benchmarks, som virksomheden selv har rapporteret, fyldte udvidelsens indbyggede indeks 136 MB for 1 million vektorer med 768 dimensioner mod 2,0 GB for HNSW på halfvec og 4,1 GB for vektorer i fuld størrelse.

Udgivelsen blev præsenteret i et annonceringsindlæg skrevet af Harshita Daddala og Anthony Mahanna. Ifølge indlægget er den mest almindelige måde at køre vektorsøgning i Postgres på at bruge et grafindeks som HNSW, der kræver stadig mere hukommelse for at opretholde ydeevnen, tager lang tid at opbygge og giver lavere nøjagtighed ved filtreret søgning. Når en forespørgsel er afgrænset til én bruger eller én lejer, kan et grafindeks returnere færre rækker end forespørgslens LIMIT. pg_pinecone anvender i stedet filteret under søgningen. Pinecone siger, at det gør det muligt stadig at returnere et fuldt sæt resultater ved en snæver afgrænsning, og at dataene aldrig forlader Postgres, når standardmotoren bruges.

Tre motorer bag ét indeks

pg_pinecone fungerer sammen med vektorkolonner, der allerede ligger i pgvector. En applikation opretter forbindelse til Postgres på samme måde og sender den samme SQL, f.eks. ORDER BY embedding <=> $1 LIMIT 10, mens tabellerne, herunder de fulde vektorer, bliver, hvor de er, og Postgres forbliver den autoritative datakilde.

Hver tabel bruger én af tre motorer. Den indbyggede motor, som er standard, opbygger og søger i sit indeks udelukkende i Postgres uden en Pinecone-konto, API-nøgle eller netværkskald. pgvector-motoren søger i et eksisterende pgvector-indeks, HNSW eller IVFFlat, og projektets GitHub-kodearkiv beskriver den som egnet til tabeller, der allerede har et pgvector-indeks, og som ikke bruger filtre. Fjernmotoren sender søgningen til et serverløst indeks i Pinecones administrerede tjeneste og er beregnet til tabeller, der er vokset ud over én Postgres-server. Det kræver ét kald til pinecone.set_engine() at skifte motor for en tabel, forespørgslerne ændres ikke, og hvert skift kan fortrydes.

Sådan søger den indbyggede motor

Ligesom pgvectors HNSW bruger den indbyggede motor en algoritme til tilnærmet nærmeste nabo, men erstatter grafen med et inverteret filindeks, der grupperer lignende vektorer i klynger. Hver vektor lagres som en kvantiseret RaBitQ-kode, der fylder omkring én bit pr. dimension plus nogle få korrektionsværdier, ved hjælp af en metode, som indlægget tilskriver Gao og Long, SIGMOD 2024. Koderne for hver klynge pakkes sammen, så en søgning læser nogle få sammenhængende sider i stedet for at springe rundt i en graf.

En søgning foregår i tre trin: Først undersøges de nærmeste klynger ved at sammenligne forespørgselsvektoren med centrum for hver klynge. Derefter beregnes en estimeret afstand for hver række ud fra dens RaBitQ-kode, og de bedste kandidater udvælges. Til sidst rangeres kandidaterne på ny ved hjælp af deres fulde vektorer fra tabellen.

Filtreringen foregår som en del af søgningen. Pinecone siger, at pgvectors HNSW anvender filtre bagefter: Først finder det de nærmeste naboer, og derefter anvender det WHERE-betingelsen, så et snævert filter frasorterer de fleste kandidater. Iterative scanninger fylder listen op igen, hvilket koster tid og – når relaxed_order bruges – nøjagtighed. Den indbyggede motor gemmer én værdi fra filterkolonnen ved siden af hver rækkes kode og tæller antallet af rækker for hver værdi under opbygningen. Ved snævre filtre, som som standard omfatter højst 3 % af rækkerne, anvender den filteret på forhånd: Den gennemgår alle rækker, der matcher, på tværs af alle klynger og beregner en score for hver ved hjælp af dens fulde vektor, så resultaterne er nøjagtige. Ved bredere filtre bruger den filtrering i ét trin: Den søger i op til halvdelen af de nærmeste klynger og kontrollerer filteret i hver klynge, før den beregner scorerne.

Nye indsættelser føjes til den nærmeste klynge og kan straks søges frem. Da klyngernes centre forbliver dér, hvor opbygningen placerede dem, anbefaler indlægget, at man kører REINDEX eller aktiverer automatisk vedligeholdelse efter store ændringer, f.eks. en masseindlæsning, der fordobler tabellen, for at omfordele klyngerne.

Benchmarks rapporteret af Pinecone

Pinecone sammenlignede den indbyggede motor med pgvectors HNSW-indeks ved hjælp af vektorer i fuld størrelse og halfvec på 1 million wiki_dpr-vektorer med 768 dimensioner. Testene blev kørt på en AWS r6id.4xlarge-instans med 16 vCPU’er og 128 GB RAM. Ufiltreret latenstid, opbygningstid og indeksstørrelse blev målt i én session på PostgreSQL 17, filtreret søgning i en anden session på PostgreSQL 18 og en konfiguration med begrænset hukommelse i en tredje session. Latenstiden rapporteres som medianen p50 ved k=10 med én klient, og virksomheden oplyste, at den fulde opsætning og kommandoerne til at køre testene igen findes i en README-fil til et benchmarkværktøj i kodearkivet.

For de 1 million vektorer rapporterede Pinecone et indbygget indeks på 136 MB mod 2,0 GB for HNSW på halfvec og 4,1 GB for vektorer i fuld størrelse. Ved ufiltreret søgning rapporterede virksomheden en latenstid på 1,3 ms ved 0,95 recall mod 1,7 ms for HNSW på halfvec og 2,7 ms for vektorer i fuld størrelse samt 2,3 ms ved 0,99 recall mod henholdsvis 4,7 ms og 6,7 ms. Med et filter, der matchede 10 % af rækkerne, rapporterede Pinecone, at den indbyggede motor opnåede 1.000 recall på 12,3 ms med filtrering i ét trin, mens HNSW med iterative scanninger højst opnåede 0,920 recall på 5,9 ms. Med et filter på 1 % rapporterede virksomheden 0,981 recall på 8,3 ms. Opbygningstiderne var ifølge rapporten 45 sekunder for den indbyggede motor mod 62 sekunder for HNSW på halfvec og 79 sekunder for vektorer i fuld størrelse.

Tilgængelighed og valgfrie Pinecone-funktioner

pg_pinecone kræver PostgreSQL 17 eller 18, adgang som superbruger og pgvector installeret på serveren. Det kan installeres fra forudbyggede udgivelser på GitHub eller som pineconeteam/pg_pinecone-imaget på Docker Hub. I README-filen beskrives det som pgvector/pgvector-imaget med pg_pinecone tilføjet, udgivet med ét tag pr. større Postgres-version, f.eks. 0.11.0-pg17. Hvis den eksterne motor skal køre, kræver det også, at udvidelsen indlæses via shared_preload_libraries. Opsætningen opretter udvidelserne vector og pg_pinecone og bygger et indeks med et kald til pinecone.create_index(). Projektet kan også bygges fra kildekoden med en Rust-værktøjskæde og cargo-pgrx 0.19.2.

Med en valgfri Pinecone API-nøgle synkroniserer den eksterne motor indlejringer til et Pinecone-indeks i baggrunden, mens søgninger fortsat kører i Postgres, indtil kopieringen er færdig. Indlægget beskriver yderligere tre valgfrie funktioner: embed() kalder Pinecones inferenstjeneste for at omdanne tekst til indlejringer fra SQL, fungerer med både den indbyggede og den eksterne motor og er dækket af Pinecones gratisniveau til den første opbygning; BM25-fuldtekstsøgning kører sammen med vektorsøgning i samme tabel, og BM25-, vektor- eller hybridsøgninger kan udføres fra SQL; og rerank() omorganiserer de bedste resultater ved hjælp af Pinecones omrangeringsmodeller.

Dokumentationen på docs.pinecone.io dækker installation, lagringsmotorerne, skift mellem motorer og fuldtekstsøgning, mens kodearkivet også indeholder en SQL-reference, en driftsvejledning for operatører og en vejledning i nødgenopretning. Pinecone beskrev dette som projektets første udgivelse, sagde, at virksomheden vedligeholder pg_pinecone og gennemgår hver pull request, og oplyste, at den vil udarbejde den offentlige køreplan på baggrund af feedback, der deles via GitHub-issues, Discord-fællesskabet og de månedlige åbne spørgetimer.