Pinecone lance Pg_pinecone, une extension de recherche open source pour Postgres

Le 27 octobre 2026, Pinecone a lancé pg_pinecone, une extension Postgres open source sous licence Apache 2.0 qui apporte aux colonnes pgvector déjà utilisées par les applications le moteur de recherche vectorielle que l’entreprise affirme exploiter à grande échelle. Selon les tests comparatifs publiés par l’entreprise, l’index natif de l’extension pour 1 million de vecteurs de 768 dimensions mesurait 136 MB, contre 2,0 GB pour HNSW sur halfvec et 4,1 GB sur des vecteurs de taille standard.

Le lancement a été présenté dans un article d’annonce rédigé par Harshita Daddala et Anthony Mahanna. Selon cet article, la méthode la plus courante pour effectuer une recherche vectorielle dans Postgres consiste à utiliser un index en graphe tel que HNSW, qui nécessite toujours plus de mémoire pour maintenir ses performances, prend beaucoup de temps à construire et perd en précision lors des recherches avec filtre. Lorsqu’une requête est limitée à un utilisateur ou à un locataire, un index en graphe peut renvoyer moins de lignes que la valeur indiquée par LIMIT. pg_pinecone applique plutôt le filtre pendant la recherche, ce qui, selon Pinecone, permet de renvoyer un ensemble complet de résultats même lorsque le champ de recherche est restreint. Avec le moteur par défaut, les données ne quittent jamais Postgres.

Trois moteurs derrière un même index

pg_pinecone fonctionne avec les colonnes vectorielles déjà stockées dans pgvector. L’application se connecte à Postgres de la même manière et envoie le même SQL, par exemple ORDER BY embedding <=> $1 LIMIT 10, tandis que les tables, y compris les vecteurs complets, restent à leur emplacement et que Postgres demeure le système de référence.

Chaque table utilise l’un des trois moteurs. Le moteur natif, sélectionné par défaut, construit son index et effectue les recherches entièrement dans Postgres, sans compte Pinecone, clé API ni appels réseau. Le moteur pgvector interroge un index pgvector existant, HNSW ou IVFFlat. Le dépôt GitHub du projet le présente comme adapté aux tables qui possèdent déjà un index pgvector et ne nécessitent pas de filtrage. Le moteur distant envoie les recherches vers un index sans serveur dans le service géré de Pinecone ; il est destiné aux tables qui ont dépassé les capacités d’un seul serveur Postgres. Pour faire passer une table d’un moteur à l’autre, un seul appel à pinecone.set_engine() suffit. Les requêtes restent inchangées et chaque changement peut être annulé.

Fonctionnement du moteur natif

Comme HNSW dans pgvector, le moteur natif utilise un algorithme de recherche approximative des plus proches voisins, mais remplace le graphe par un index à fichiers inversés qui regroupe les vecteurs similaires en clusters. Chaque vecteur est stocké sous la forme d’un code RaBitQ quantifié, représentant environ un bit par dimension auquel s’ajoutent quelques valeurs de correction. L’article attribue cette méthode à Gao et Long, dans leurs travaux publiés à SIGMOD 2024. Les codes de chaque cluster sont regroupés, de sorte qu’une recherche lit quelques pages contiguës au lieu de parcourir un graphe par bonds.

Une recherche se déroule en trois étapes : elle repère les clusters les plus proches en comparant le vecteur de la requête au centroïde de chaque cluster, calcule une distance estimée pour chaque ligne à partir de son code RaBitQ et conserve les meilleurs candidats, puis reclasse ces candidats à l’aide des vecteurs complets stockés dans la table.

Le filtrage s’effectue pendant la recherche. Selon Pinecone, HNSW dans pgvector applique le filtre après la recherche : il trouve d’abord les plus proches voisins, puis applique la clause WHERE. Un filtre très restrictif élimine donc la plupart des candidats, et les balayages itératifs complètent la liste au prix d’un allongement du temps de traitement et, lorsque relaxed_order est utilisé, d’une perte de précision. Le moteur natif stocke une valeur de la colonne de filtrage à côté du code de chaque ligne et dénombre les lignes pour chaque valeur au moment de la construction de l’index. Pour les filtres très restrictifs, soit 3 % des lignes ou moins par défaut, il applique d’abord le filtre : il parcourt toutes les lignes correspondantes dans l’ensemble des clusters et évalue chacune à l’aide de son vecteur complet, ce qui garantit des résultats exacts. Pour les filtres plus larges, il utilise un filtrage en une seule étape : il explore jusqu’à la moitié des clusters les plus proches et vérifie le filtre dans chaque cluster avant l’évaluation.

Les nouvelles insertions rejoignent le cluster le plus proche et peuvent être recherchées immédiatement. Comme les centroïdes restent à l’emplacement qui leur a été attribué lors de la construction de l’index, l’article recommande d’exécuter REINDEX ou d’activer la maintenance automatique après des changements importants, par exemple lorsqu’un chargement en bloc double la taille de la table, afin de rééquilibrer les clusters.

Résultats des tests comparatifs publiés par Pinecone

Pinecone a comparé le moteur natif à l’index HNSW de pgvector, avec des vecteurs de taille standard et halfvec, sur 1 million de vecteurs wiki_dpr de 768 dimensions. Les tests ont été exécutés sur une instance AWS r6id.4xlarge dotée de 16 vCPU et de 128 GB de mémoire vive. La latence sans filtrage, le temps de construction et la taille de l’index ont été mesurés au cours d’une session sur PostgreSQL 17 ; la recherche avec filtre, lors d’une autre session sur PostgreSQL 18 ; et une configuration à mémoire limitée, au cours d’une troisième session. La latence est indiquée sous la forme de la médiane p50 avec k=10 et un seul client. L’entreprise précise que la configuration complète et les commandes permettant de relancer les tests figurent dans un fichier README du banc d’essai, dans le dépôt.

Pour les 1 million de vecteurs, Pinecone a indiqué que l’index natif mesurait 136 MB, contre 2,0 GB pour HNSW sur halfvec et 4,1 GB sur des vecteurs de taille standard. Pour les recherches sans filtre, l’entreprise a rapporté une latence de 1,3 ms avec un rappel de 0,95, contre 1,7 ms pour HNSW sur halfvec et 2,7 ms sur des vecteurs de taille standard, ainsi qu’une latence de 2,3 ms avec un rappel de 0,99, contre 4,7 ms et 6,7 ms. Avec un filtre correspondant à 10 % des lignes, Pinecone a indiqué que le moteur natif atteignait un rappel de 1,000 en 12,3 ms avec le filtrage en une seule étape, tandis que HNSW avec balayages itératifs atteignait au mieux un rappel de 0,920 en 5,9 ms. Avec un filtre de 1 %, l’entreprise a rapporté un rappel de 0,981 en 8,3 ms. Le temps de construction annoncé était de 45 secondes pour le moteur natif, contre 62 secondes pour HNSW sur halfvec et 79 secondes sur des vecteurs de taille standard.

Disponibilité et fonctionnalités Pinecone facultatives

pg_pinecone nécessite PostgreSQL 17 ou 18, un accès superutilisateur et l’installation de pgvector sur le serveur. Il peut être installé à partir des versions précompilées disponibles sur GitHub ou de l’image pineconeteam/pg_pinecone sur Docker Hub. Le README la décrit comme l’image pgvector/pgvector à laquelle pg_pinecone a été ajouté, publiée avec une balise par version majeure de Postgres, par exemple 0.11.0-pg17. L’exécution du moteur distant nécessite également le chargement de l’extension via shared_preload_libraries. La configuration crée les extensions vector et pg_pinecone, puis construit un index à l’aide d’un appel à pinecone.create_index(). Le projet peut aussi être compilé à partir des sources avec une chaîne d’outils Rust et cargo-pgrx 0.19.2.

Avec une clé API Pinecone facultative, le moteur distant synchronise les embeddings avec un index Pinecone en arrière-plan, tandis que les recherches continuent de s’exécuter dans Postgres jusqu’à la fin de la copie. L’article présente trois autres fonctionnalités facultatives : embed() fait appel au service d’inférence de Pinecone pour convertir du texte en embeddings depuis SQL, fonctionne avec les moteurs natif et distant, et peut être utilisé lors d’une première création grâce à l’offre gratuite de Pinecone ; la recherche en texte intégral BM25 s’exécute parallèlement à la recherche vectorielle dans la même table, et les requêtes BM25, vectorielles ou hybrides sont lancées depuis SQL ; enfin, rerank() réordonne les meilleurs résultats à l’aide des modèles de reclassement de Pinecone.

La documentation disponible sur docs.pinecone.io couvre l’installation, les moteurs de stockage, le changement de moteur et la recherche en texte intégral. Le dépôt propose également une référence SQL, un guide d’exploitation et un guide de reprise après sinistre. Pinecone a présenté cette version comme la première du projet, indiqué qu’il assure la maintenance de pg_pinecone et examine chaque demande de fusion, et précisé qu’il élaborera la feuille de route publique à partir des commentaires transmis via les problèmes GitHub, sa communauté Discord et ses permanences mensuelles.