Prix d'une base de données vectorielle : ce que vous payez vraiment

Le prix d'une base de données vectorielle ne se résume pas à un tarif affiché. Vous payez en réalité de la mémoire et du stockage (selon le nombre de vecteurs et leurs dimensions), du calcul pour les requêtes et l'indexation, et autant de copies que vous gardez de réplicas. S'y ajoutent des coûts absents de la facture : le calcul des embeddings, la réindexation complète à chaque changement de modèle et le temps d'ingénierie. Cet article détaille chaque poste, montre comment estimer la mémoire par un calcul d'ordre de grandeur et vous aide à décider si une base vectorielle vous est vraiment utile.

Ce que contient vraiment une base vectorielle

Une base vectorielle stocke des embeddings : des listes de nombres qui représentent le sens d'un passage de texte. Chaque document est découpé en morceaux (chunks) et chaque morceau reçoit son propre vecteur. Si la notion vous paraît floue, lisez d'abord Qu'est-ce qu'une base de données vectorielle ?, puis revenez ici pour la partie budget.

Premier enseignement pour le coût : vous ne payez pas au document, mais au vecteur. Un PDF de 50 pages peut donner 50 vecteurs ou 500 selon la taille des morceaux et leur chevauchement. Ce choix de découpage, souvent fait une fois puis oublié, peut faire varier la facture d'un facteur dix.

Les quatre leviers qui font la facture

Que vous hébergiez un moteur open source, ajoutiez une extension à PostgreSQL ou passiez par un service managé, les mêmes ressources physiques sont en jeu. Les fournisseurs les découpent différemment (à l'heure, au gigaoctet, à l'unité de lecture), mais les leviers restent ces quatre-là.

1. Le nombre de vecteurs

C'est la base de tout calcul. Comptez vos morceaux, pas vos fichiers, et prévoyez la croissance : si votre fonds documentaire double en un an, votre index aussi.

2. Les dimensions et la précision

Le modèle d'embedding fixe le nombre de dimensions : 384, 768, 1 024, 1 536 ou 3 072 sont des tailles courantes. En float32, chaque dimension occupe 4 octets. Un vecteur de 1 536 dimensions pèse donc environ 6 Ko, avant tout surcoût d'index.

3. Le volume de requêtes et la latence visée

Les index de recherche approximative des plus proches voisins, comme les graphes HNSW décrits dans l'article de recherche d'origine, répondent vite parce qu'ils parcourent un graphe au lieu de tout comparer. Pour rester rapides, ils doivent tenir en mémoire vive. Plus de requêtes par seconde, une latence plus serrée et des filtres sur les métadonnées demandent davantage de RAM et de processeur.

4. Les réplicas et les environnements

Une seule copie de l'index est un point de défaillance unique. En production, on compte en général deux ou trois réplicas, chacun avec l'index complet. Ajoutez un environnement de recette, voire un index par client pour cloisonner les données, et les mêmes vecteurs sont payés plusieurs fois.

Estimer le coût de stockage des embeddings par le calcul

Nul besoin d'une grille tarifaire pour estimer la mémoire. La formule est : nombre de vecteurs × dimensions × 4 octets (en float32). Voici quelques ordres de grandeur, avant surcoût d'index, métadonnées et réplicas.

Exemple : 1 000 000 × 1 536 × 4 = 6 144 000 000 octets, soit environ 6,1 Go. Ce n'est qu'un point de départ. Un index en graphe stocke des liens vers les voisins de chaque vecteur, vous conservez généralement le texte des morceaux et leurs métadonnées, puis vous multipliez par le nombre de réplicas. Un fonds qui semblait tenir dans 6 Go réclame vite plusieurs dizaines de gigaoctets de RAM sur l'ensemble du cluster.

Les coûts cachés : embeddings, réindexation et temps humain

• Le calcul des embeddings. Chaque morceau passe par un modèle d'embedding à l'ingestion, et chaque question est vectorisée au moment de la recherche. Que vous appeliez une API ou fassiez tourner vos propres GPU, c'est un coût récurrent.
• La réindexation au changement de modèle. Les vecteurs de deux modèles différents ne sont pas comparables. Changer de modèle, ou même de dimension, impose de recalculer et de réindexer tout le fonds, souvent en gardant l'ancien index en service pendant la bascule.
• Le redécoupage. Si les réponses sont médiocres et que vous changez de stratégie de découpage, tout est à recalculer. Attendez-vous à le faire plusieurs fois au début.
• Les mises à jour et suppressions. Garder les vecteurs synchronisés avec les documents sources exige un pipeline, et certains index se dégradent après de nombreuses suppressions.
• Les sauvegardes et transferts. Instantanés et copies entre régions ajoutent du stockage et des frais de sortie de données.
• L'exploitation. Réglage des paramètres, suivi de la qualité, montées de version et astreinte : quelqu'un doit en être responsable.

Il faut aussi compter la conformité. Au sens du RGPD, des embeddings calculés à partir de textes contenant des données personnelles, et stockés à côté de ces textes, doivent être traités comme des données personnelles : contrôle d'accès, durée de conservation, registre des traitements, localisation de l'hébergement. Les ressources de la CNIL sur l'intelligence artificielle aident à cadrer ces questions, d'autant que l'AI Act ajoute ses propres obligations selon les usages.

Quand vous n'avez pas besoin d'une base vectorielle

• Votre fonds est petit. Quelques milliers de morceaux tiennent sans peine en mémoire et une comparaison exhaustive reste rapide.
• Vos questions portent sur des termes exacts. Numéros d'articles de loi, références produit, codes d'erreur, noms propres : la recherche plein texte les trouve souvent mieux que la seule similarité sémantique. Une recherche hybride, qui combine mots-clés et sens, fait fréquemment mieux que les vecteurs seuls.
• Vous utilisez déjà PostgreSQL. Une extension vectorielle garde les embeddings à côté de vos données relationnelles, avec une seule politique de sauvegarde et de droits.
• Vous voulez des réponses, pas une infrastructure. Si l'objectif est que vos équipes ou vos assistants IA interrogent des documents, un service managé supprime la base, le pipeline d'embeddings et la question de la réindexation.

Ce dernier cas correspond au RAG as a service. Avec Kopik, vous créez gratuitement une base en déposant des PDF, des fichiers Word, du texte ou du Markdown ; Kopik extrait, découpe et indexe pour une recherche hybride (plein texte et élargissement sémantique des mots-clés). Pas de cluster à dimensionner ni de dimensions à choisir : les questions se paient en crédits prépayés, ou via l'abonnement chat à 12 € par mois avec jauge d'usage. Pour comprendre ce que deviennent vos fichiers, lisez Chunking, indexation, recherche : comment fonctionne un pipeline RAG.

La liste de contrôle avant de comparer les offres

1. Comptez vos morceaux aujourd'hui et estimez-les à 12 mois.
2. Choisissez la dimension des embeddings et calculez vecteurs × dimensions × 4 octets.
3. Testez la quantification sur 50-100 vraies questions.
4. Fixez le nombre de réplicas et d'environnements (production, recette, par client).
5. Estimez les requêtes par jour et le pic par seconde, en tenant compte des agents IA qui cherchent en boucle.
6. Budgétez les embeddings pour le chargement initial, les mises à jour et au moins une réindexation complète par an.
7. Vérifiez l'hébergement des données (UE ou non), le chiffrement et la journalisation inclus dans chaque offre.
8. Chiffrez le temps de votre équipe pour faire tourner et maintenir le tout.