Présentation de pg_vectorsearch

pg_vectorsearch est une extension PostgreSQL en phase alpha destinée aux recherches de voisins les plus proches approximatives (ANN). Elle s’installe via CREATE EXTENSION pg_vectorsearch; et fonctionne avec PostgreSQL 18+ et un compilateur C11 (GCC 11+ ou Clang 14+). L’extension est compatible avec les colonnes vector et halfvec de pgvector, ce qui permet de créer un index PRISM sans modifier les tables existantes. Le projet indique que les mises à jour entre pré‑releases peuvent nécessiter la suppression puis la recréation de l’extension et de ses index.

Architecture PRISM et quantification RaBitQ

Le cœur de pg_vectorsearch est l’index PRISM (Partitioned Routing Index for Similarity Matching). PRISM utilise un arbre de centroïdes hiérarchique pour partitionner les vecteurs, rappelant le modèle IVF de pgvector mais enrichi d’un routage à plusieurs niveaux. Chaque vecteur est encodé avec la quantification RaBitQ, une technique binaire qui fournit des bornes d’erreur théoriques. Ces bornes permettent d’écarter rapidement les vecteurs qui ne peuvent pas être parmi les plus proches, limitant ainsi le nombre de comparaisons en pleine précision. Les vecteurs quantifiés sont stockés dans des listes de publication dont la mise en page de page est optimisée pour le calcul SIMD (AVX2, AVX512, NEON). Le code source indique que le calcul de distance exploite ces instructions vectorielles pour réduire le temps de traitement par vecteur.

Flux de requête et performances comparatives

Le processus de recherche s’articule en cinq étapes : (1) traversée de l’arbre de centroïdes pour identifier les clusters les plus proches, (2) scan des listes de publication, (3) filtrage à deux étapes grâce à RaBitQ (estimation → borne d’erreur → rerank), (4) rerank en pleine précision à partir du tas, (5) renvoi des k voisins. Sur un jeu de données de 100 millions de vecteurs, PRISM atteint une vitesse de requête supérieure à celle de HNSW tout en conservant un rappel d’environ 0,95, avec seulement un quart de la mémoire utilisée. Les benchmarks internes montrent également que la construction d’un index PRISM est plus rapide que celle d’un index IVFFlat, grâce à l’insertion directe dans les listes de publication et à l’absence de phase de ré‑indexation massive.

CREATE EXTENSION pg_vectorsearch;
CREATE TABLE items (
    id serial PRIMARY KEY,
    embedding vec32(3) STORAGE PLAIN
);
INSERT INTO items (embedding)
SELECT ARRAY[i::real, (i % 7)::real, (i % 5)::real]::vec32
FROM generate_series(1, 1000) i;
CREATE INDEX ON items USING prism (embedding vec32_l2_ops);
SET prism.nprobe = 40;
SELECT * FROM items
ORDER BY embedding <-> '[3,1,2]' LIMIT 5;

Déploiement, maintenance et limites

pg_vectorsearch propose deux modes d’utilisation : des colonnes natives vec32/vec16 pour les nouveaux projets, ou un index PRISM construit sur des colonnes existantes de pgvector. Dans les deux cas, les opérateurs (<->, <#>, <=>) et les classes d’opérateurs restent identiques, ce qui évite toute modification de requêtes. Les mises à jour dynamiques (insert, update, delete) sont gérées via des ajouts aux listes de publication ; les listes ne se scindent pas automatiquement. La procédure prism_rebalance permet de scinder manuellement les listes surdimensionnées. Le guide de maintenance précise que la ré‑indexation reste la méthode la plus fiable pour des changements majeurs de distribution. Enfin, l’état alpha de l’extension implique que la stabilité en production n’est pas garantie et que les utilisateurs doivent prévoir des tests de charge avant le déploiement à grande échelle.