Timescale publie pg_vectorsearch pour un indexage vectoriel haute performance dans PostgreSQL

Timescale a publié pg_vectorsearch, une nouvelle extension PostgreSQL conçue pour accélérer la recherche approximative des voisins les plus proches (ANN) sur des données vectorielles. Publiée le 14 octobre 2026, cet outil en phase alpha introduit l'index PRISM, qui vise à surpasser les solutions existantes comme HNSW et IVFFlat en termes de vitesse et d'efficacité mémoire. Cette sortie s'adresse aux développeurs construisant des systèmes de génération augmentée par récupération (RAG) qui ont besoin d'une infrastructure vectorielle évolutive au sein de leurs bases de données relationnelles existantes.

Ce qui s'est passé

Le cœur de cette sortie est l'index PRISM, qui signifie Partitioned Routing Index for Similarity Matching. Il est implémenté en C pour assurer une intégration étroite avec les composants internes de PostgreSQL. Selon l'annonce, PRISM est nettement plus rapide que les index IVFFlat et HNSW de pgvector, tant pour les requêtes que pour la construction de l'index. Dans des benchmarks impliquant un jeu de données de 100 millions de vecteurs, PRISM a atteint un rappel équivalent à celui de HNSW basé sur graphes tout en utilisant seulement un quart de la mémoire et en offrant des temps de requête plus rapides.

Cette extension prend en charge les mises à jour dynamiques, permettant des insertions, des mises à jour et des suppressions sans nécessiter une reconstruction complète de l'index. Cependant, les mainteneurs indiquent explicitement que le logiciel est actuellement en statut alpha et qu'il est destiné aux tests plutôt qu'à une utilisation en production. La mise à niveau entre les préversions peut ne pas être possible ; il est donc conseillé aux utilisateurs de prévoir la suppression et la recréation de l'extension et de ses index à mesure que le projet évolue. Les problèmes connus sont suivis dans le changelog.

Comment cela fonctionne

PRISM utilise un arbre hiérarchique de centroïdes pour partitionner les vecteurs en clusters, s'appuyant sur le cache de tampons de PostgreSQL pour maintenir cette structure de routage en mémoire. Cette approche permet au système d'identifier rapidement les clusters pertinents sans scanner l'ensemble du jeu de données. Une fois les clusters les plus proches identifiés, le système scanne les listes de postings pour générer des vecteurs candidats. Ces listes sont optimisées pour le calcul de distance SIMD, utilisant les instructions AVX2, AVX512 et NEON pour accélérer les calculs sur le matériel compatible.

Une caractéristique technique clé est l'utilisation de la quantification RaBitQ. Cette méthode encode les vecteurs avec des limites d'erreur théoriques, permettant un processus de recherche en deux étapes. La première étape estime les distances et utilise les limites d'erreur pour écarter les vecteurs qui ne peuvent pas être des voisins les plus proches. Cette étape de filtrage réduit considérablement le nombre de candidats nécessitant un reclassement contre des vecteurs en précision pleine stockés dans le tas de la table. L'étape finale renvoie les k voisins les plus proches après ce processus efficace de filtrage et de reclassement.

Détails clés

• Type d'index : PRISM (Partitioned Routing Index for Similarity Matching), qui est de type IVF avec routage hiérarchique.
• Quantification : Utilise la quantification RaBitQ avec des limites d'erreur théoriques pour un filtrage efficace de la recherche en deux étapes.
• Accélération matérielle : Les calculs de distance sont optimisés pour les instructions SIMD, y compris AVX2, AVX512 et NEON.
• Compatibilité : Peut indexer directement les colonnes vector et halfvec existantes de pgvector, ou utiliser les types natifs vec32 et vec16.
• Maintenance : Prend en charge les insertions, mises à jour et suppressions dynamiques, avec des scissions de listes de postings gérées via la procédure prism_rebalance.
• Statut : Sortie alpha destinée aux tests ; la mise à niveau entre les préversions peut nécessiter la suppression et la recréation des index.

Pourquoi c'est important

Pour les ingénieurs développant des applications IA, les performances de la recherche vectorielle deviennent souvent un goulot d'étranglement à mesure que les jeux de données croissent. Les index traditionnels basés sur graphes comme HNSW peuvent consommer beaucoup de mémoire, augmentant ainsi les coûts d'infrastructure. En démontrant que PRISM peut gérer 100 millions de vecteurs avec une fraction de la mémoire requise par HNSW, cette extension offre une voie vers une mise à l'échelle plus rentable. Elle permet aux équipes de conserver leurs données vectorielles aux côtés de leurs données transactionnelles dans PostgreSQL, simplifiant l'architecture et réduisant le besoin de services de base de données vectorielles séparés.

La compatibilité avec les tables pgvector existantes est particulièrement importante pour la migration. Les développeurs n'ont pas besoin de réécrire leurs schémas ou leur logique applicative pour tester le nouvel index. Ils peuvent installer pg_vectorsearch aux côtés de pgvector et construire un index PRISM sur des colonnes existantes. Cela abaisse la barrière à l'entrée pour évaluer si les gains de performance justifient la complexité opérationnelle de l'adoption d'une nouvelle méthode d'indexation, même à son stade alpha précoce.

Ce que vous pouvez faire

• Installez PostgreSQL 18 ou ultérieur ainsi qu'un compilateur GNU C11 tel que GCC 11+ ou Clang 14+ pour préparer votre environnement.
• Construisez l'extension depuis les sources en utilisant le système de build Meson, en veillant à disposer des en-têtes de développement PostgreSQL nécessaires.
• Testez l'extension sur des jeux de données non critiques en créant un index PRISM sur des colonnes vector ou halfvec existantes.
• Expérimentez avec le paramètre prism.nprobe pour ajuster le compromis entre la vitesse de requête et la précision du rappel pour votre charge de travail spécifique.
• Surveillez le changelog pour les problèmes connus et soyez prêt à supprimer et recréer les index lors des tests de nouvelles versions préliminaires.
• Évaluez la procédure prism_rebalance pour maintenir les performances de l'index lors des opérations dynamiques d'insertion et de mise à jour.