Aller au contenu principal
ValidéBaptiste2026-08-07

Utiliser PostgreSQL avec pgvector comme stockage vectoriel par défaut

Statut de la décision​

Acceptée

Contexte​

Les options A2.4 et A3.2 nécessitent un stockage pour les embeddings, les métadonnées et la recherche sémantique.

Alpene utilise déjà PostgreSQL pour les données applicatives et l'exploitation. Ajouter une base vectorielle dédiée à chaque projet augmente le nombre de services, les sauvegardes, la supervision et les procédures de reprise.

Certains projets peuvent néanmoins nécessiter des fonctions ou performances vectorielles plus avancées.

Décision​

PostgreSQL avec pgvector est le stockage vectoriel de référence pour A2.4 et A3.2.

Qdrant est retenu uniquement lorsqu'un benchmark ou une contrainte démontre que pgvector ne suffit pas.

Le stockage vectoriel natif d'une brique applicative n'est utilisé que s'il reste exportable et ne crée pas de dépendance incompatible avec la réversibilité.

Options considérées​

PostgreSQL avec pgvector​

PostgreSQL avec pgvector conserve les vecteurs, métadonnées et données applicatives dans un service déjà maîtrisé.

Cette option est retenue par défaut car elle réduit la surface opérationnelle et facilite la sauvegarde, la restauration et la restitution.

Qdrant​

Qdrant est une base vectorielle dédiée avec des capacités spécialisées de recherche, filtrage et exploitation à grande échelle.

Elle n'est pas retenue par défaut car elle ajoute un service à déployer, sauvegarder, superviser et maintenir. Elle devient pertinente lorsque la volumétrie, les filtres, l'isolation ou les performances le justifient.

Stockage natif de l'application​

Une brique A3 peut fournir son propre stockage vectoriel.

Cette option n'est pas retenue comme référence car elle couple les données documentaires à l'application de chat et peut compliquer un changement de produit.

Critères de passage à Qdrant​

Qdrant peut être retenu lorsque :

  • la volumétrie dépasse les capacités validées de pgvector ;
  • les filtres de métadonnées deviennent complexes ;
  • les objectifs de latence ne sont pas atteints ;
  • un service vectoriel dédié simplifie l'isolation ;
  • le benchmark du corpus client montre un avantage réel ;
  • l'exploitation du service supplémentaire est acceptée.

Conséquences​

Gains​

  • Moins de services par défaut.
  • Sauvegarde et restauration intégrées au socle PostgreSQL.
  • Métadonnées et relations disponibles dans la même base.
  • Réversibilité plus simple.
  • Stack commune entre A2.4 et A3.2.

Coûts acceptés​

  • pgvector peut atteindre ses limites sur certains volumes ou profils de recherche.
  • Une migration vers Qdrant peut devenir nécessaire.
  • Les performances doivent être testées avec un corpus représentatif.

Règles d'exploitation​

  • Le modèle d'embedding et sa version sont enregistrés avec chaque index.
  • Un changement de modèle d'embedding déclenche une réindexation complète.
  • La suppression d'un document supprime ses fragments et vecteurs.
  • Les sauvegardes incluent les vecteurs et métadonnées.
  • Les identifiants séparent les clients et collections.

Conditions de révision​

Cette décision sera revue si un benchmark démontre que Qdrant ou une autre base dédiée apporte un avantage nécessaire qui compense son coût opérationnel.