Pinecone rilascia Pg_pinecone, un’estensione open source per la ricerca in Postgres

Il 27 ottobre 2026 Pinecone ha rilasciato pg_pinecone, un’estensione open source per Postgres con licenza Apache 2.0, che porta nelle colonne pgvector già utilizzate dalle applicazioni il motore di ricerca vettoriale che, secondo l’azienda, utilizza su larga scala. Nei benchmark comunicati dall’azienda, l’indice nativo dell’estensione per 1 milione di vettori a 768 dimensioni occupava 136 MB, contro i 2,0 GB di HNSW su halfvec e i 4,1 GB sui vettori a dimensione intera.

La release è stata presentata in un post di annuncio scritto da Harshita Daddala e Anthony Mahanna. Secondo il post, il metodo più comune per eseguire ricerche vettoriali in Postgres consiste nell’usare un indice a grafo come HNSW, che richiede quantità sempre maggiori di memoria per mantenere le prestazioni, impiega molto tempo a essere creato e riduce la precisione nelle ricerche con filtri; quando una query è limitata a un utente o a un tenant, un indice a grafo può restituire meno righe rispetto al valore di LIMIT della query. pg_pinecone applica invece il filtro durante la ricerca e, secondo Pinecone, consente così di restituire il numero completo di risultati anche con un ambito ristretto; inoltre, con il motore predefinito, i dati non escono mai da Postgres.

Tre motori per un unico indice

pg_pinecone funziona con le colonne vettoriali già presenti in pgvector. Un’applicazione si connette a Postgres nello stesso modo e invia le stesse istruzioni SQL, per esempio ORDER BY embedding <=> $1 LIMIT 10, mentre le tabelle, compresi i vettori completi, restano dove sono e Postgres continua a essere il sistema di riferimento per i dati.

Ogni tabella utilizza uno dei tre motori. Il motore nativo, predefinito, crea e interroga il proprio indice interamente all’interno di Postgres, senza richiedere un account Pinecone, una chiave API o chiamate di rete. Il motore pgvector interroga un indice pgvector esistente, HNSW o IVFFlat; il repository GitHub del progetto lo descrive come adatto alle tabelle che dispongono già di un indice pgvector e non applicano filtri. Il motore remoto invia le ricerche a un indice serverless nel servizio gestito di Pinecone, pensato per le tabelle che hanno superato i limiti di un singolo server Postgres. Per passare da un motore all’altro per una tabella basta una chiamata a pinecone.set_engine(); le query non cambiano e ogni passaggio è reversibile.

Come funziona la ricerca con il motore nativo

Come HNSW di pgvector, il motore nativo utilizza un algoritmo approssimato dei vicini più prossimi, ma sostituisce il grafo con un indice a file invertito che raggruppa i vettori simili in cluster. Ogni vettore viene memorizzato come codice RaBitQ quantizzato, con circa un bit per dimensione più alcuni valori di correzione, usando un metodo che il post attribuisce a Gao e Long, SIGMOD 2024. I codici di ciascun cluster sono raggruppati insieme, così la ricerca legge alcune pagine contigue invece di spostarsi tra i nodi di un grafo.

La ricerca si svolge in tre passaggi: individua i cluster più vicini confrontando il vettore della query con il centroide di ciascun cluster; calcola una distanza stimata per ogni riga a partire dal relativo codice RaBitQ e seleziona i candidati migliori; infine, riordina questi candidati usando i vettori completi presenti nella tabella.

Il filtraggio avviene durante la ricerca. Secondo Pinecone, il filtro di HNSW in pgvector viene applicato dopo la ricerca dei vicini più prossimi, aggiungendo in seguito la clausola WHERE: di conseguenza, un filtro molto restrittivo elimina la maggior parte dei candidati e le scansioni iterative reintegrano l’elenco, con un costo in termini di tempo e, quando si usa relaxed_order, di precisione. Il motore nativo memorizza accanto al codice di ogni riga il valore della colonna usata per il filtro e, al momento della creazione dell’indice, conta le righe per ciascun valore. Per i filtri più restrittivi, che per impostazione predefinita riguardano il 3% delle righe o meno, applica il filtro prima della ricerca: esamina tutte le righe corrispondenti in ogni cluster e assegna un punteggio a ciascuna usando il vettore completo, così da ottenere risultati esatti. Per i filtri più ampi utilizza un filtraggio in un’unica fase: esamina fino alla metà dei cluster più vicini e controlla il filtro all’interno di ciascun cluster prima di assegnare i punteggi.

I nuovi inserimenti vengono assegnati al cluster più vicino e sono subito disponibili per la ricerca. Poiché i centroidi restano nelle posizioni definite al momento della creazione dell’indice, il post consiglia di eseguire REINDEX o attivare la manutenzione automatica dopo modifiche importanti, per esempio un caricamento in blocco che raddoppia le dimensioni della tabella, così da riequilibrare i cluster.

Benchmark presentati da Pinecone

Pinecone ha confrontato il motore nativo con l’indice HNSW di pgvector, usando vettori a dimensione intera e halfvec, su 1 milione di vettori wiki_dpr a 768 dimensioni. I test sono stati eseguiti su un’istanza AWS r6id.4xlarge con 16 vCPU e 128 GB di RAM: latenza senza filtri, tempo di creazione e dimensioni dell’indice sono stati misurati in una sessione su PostgreSQL 17; la ricerca con filtri, in un’altra sessione su PostgreSQL 18; e una configurazione con memoria limitata, in una terza sessione. La latenza è riportata come mediana p50 con k=10 e un client; l’azienda ha dichiarato che la configurazione completa e i comandi per ripetere i test sono disponibili in un README del benchmark harness nel repository.

Per 1 milione di vettori, Pinecone ha riportato un indice nativo di 136 MB, rispetto ai 2,0 GB di HNSW su halfvec e ai 4,1 GB sui vettori a dimensione intera. Nelle ricerche senza filtri, l’azienda ha rilevato una latenza di 1,3 ms con recall pari a 0,95, contro 1,7 ms per HNSW su halfvec e 2,7 ms sui vettori a dimensione intera; con recall pari a 0,99, la latenza era di 2,3 ms, rispetto a 4,7 ms e 6,7 ms. Con un filtro corrispondente al 10% delle righe, Pinecone ha riferito che il motore nativo ha raggiunto un recall di 1,000 in 12,3 ms usando il filtraggio in un’unica fase, mentre HNSW con scansioni iterative ha raggiunto al massimo un recall di 0,920 in 5,9 ms; con un filtro dell’1%, ha riportato un recall di 0,981 in 8,3 ms. I tempi di creazione dell’indice sono stati di 45 secondi per il motore nativo, contro 62 secondi per HNSW su halfvec e 79 secondi sui vettori a dimensione intera.

Disponibilità e funzionalità Pinecone opzionali

pg_pinecone richiede PostgreSQL 17 o 18, l’accesso da superutente e l’installazione di pgvector sul server. Si installa a partire dalle versioni precompilate disponibili su GitHub oppure come immagine pineconeteam/pg_pinecone su Docker Hub, che il README descrive come l’immagine pgvector/pgvector con pg_pinecone aggiunto, pubblicata con un tag per ogni versione principale di Postgres, come 0.11.0-pg17; per eseguire il motore remoto è inoltre necessario caricare l’estensione tramite shared_preload_libraries. La configurazione crea le estensioni vector e pg_pinecone e genera un indice con una chiamata a pinecone.create_index(); il progetto può anche essere compilato dai sorgenti usando una toolchain Rust e cargo-pgrx 0.19.2.

Con una chiave API Pinecone facoltativa, il motore remoto sincronizza gli embedding con un indice Pinecone in background, mentre le ricerche continuano a essere eseguite in Postgres fino al completamento della copia. L’articolo descrive altre tre funzionalità facoltative: embed() richiama il servizio di inferenza di Pinecone per convertire il testo in embedding tramite SQL, funziona sia con il motore nativo sia con quello remoto ed è coperta dal piano gratuito di Pinecone per una prima compilazione; la ricerca full-text BM25 affianca la ricerca vettoriale sulla stessa tabella, consentendo di eseguire query BM25, vettoriali o ibride da SQL; infine, rerank() riordina i risultati principali usando i modelli di riordinamento di Pinecone.

La documentazione su docs.pinecone.io tratta l’installazione, i motori di archiviazione, il passaggio da un motore all’altro e la ricerca full-text; il repository aggiunge un riferimento SQL, una guida operativa per gli operatori e una guida al ripristino di emergenza. Pinecone ha descritto questa come la prima versione del progetto, ha dichiarato di occuparsi della manutenzione di pg_pinecone e di esaminare ogni pull request, e ha affermato che elaborerà la roadmap pubblica sulla base dei feedback condivisi tramite le segnalazioni su GitHub, la community Discord e gli incontri mensili di ricevimento.