Bases de données vectorielles : laquelle choisir (et quand)
Comment marche une base de données vectorielle, quand celle que vous avez déjà suffit, et laquelle des six grandes options choisir.
Chercher par le sens : une base de données vectorielle retrouve les entrées les plus proches de votre question
Le jour où vous ajoutez à votre produit une fonction d’IA qui répond à partir de vos propres documents, il faut décider où ranger ces documents pour que le logiciel retrouve les bons, vite. Cette couche de stockage porte un nom : la base de données vectorielle. Et l’erreur la plus courante, et la plus coûteuse, consiste à se précipiter sur un outil spécialisé bien avant que le projet en ait réellement besoin. Voici ce que font vraiment ces outils, quand la base de données que vous faites déjà tourner suffit, et comment choisir parmi les six qui méritent qu’on s’y attarde : Pinecone, Weaviate, Qdrant, Milvus, Chroma et pgvector.
Ce que fait vraiment une base de données vectorielle
Une recherche classique compare des mots. Vous tapez un terme, on vous renvoie les lignes qui contiennent ce terme. Une base de données vectorielle, elle, compare le sens. Quand vous y ajoutez un document, elle passe le texte dans un modèle d’IA qui le transforme en une longue liste de nombres, une sorte de coordonnée pour l’idée que le texte exprime. Cette liste de nombres porte un nom dans le métier : un embedding. Deux passages qui parlent du même sujet se retrouvent avec des coordonnées voisines, même quand ils ne partagent aucun mot. Chercher, dès lors, revient à trouver les coordonnées les plus proches de votre question.
C’est le moteur derrière toutes ces fonctions d’IA qui répondent à partir de votre propre contenu : les assistants qui citent vos pages d’aide, la recherche qui traite « comment j’annule » et « résilier mon abonnement » comme une seule et même demande. Ce schéma a un nom, le retrieval (en anglais, « aller chercher les passages pertinents ») : le modèle lit d’abord les passages les plus utiles que vous êtes allé chercher dans le stockage, puis il rédige sa réponse ; il s’appuie ainsi sur vos données au lieu de deviner.
La seule idée à garder en tête
Côté calcul, la recherche est un problème pratiquement résolu. Presque toutes les options s’appuient sur la même famille de techniques pour retrouver vite les voisins les plus proches ; les benchmarks de vitesse, ces tests de performance face à face, ne tranchent donc presque jamais rien pour un vrai projet. Ce qui distingue ces outils, ce n’est pas leur façon de chercher, mais la part de votre exploitation qu’ils prennent en charge : faut-il faire tourner le logiciel vous-même ou le louer, comment il se comporte quand vous ne fouillez qu’une tranche de vos données, et combien de maintenance retombe sur votre équipe.
Et voici la vérité tranquille qui sous-tend toute la comparaison. La plupart des équipes montent une base de données vectorielle dédiée bien avant d’avoir assez de données pour en avoir besoin. Si votre application range déjà ses données dans une base de données ordinaire, vous pouvez très probablement ajouter la recherche par le sens à cette même base, sans jamais faire tourner un second système. Commencez par là. Ajoutez un outil spécialisé quand vous butez sur un vrai mur, pas par anticipation.
Les trois critères qui décident vraiment du choix
Vous le faites tourner, ou vous le louez. Certaines de ces solutions, vous les installez et les exploitez vous-même, sur vos propres serveurs. D’autres sont un service que vous payez sans jamais voir la machinerie derrière. Louer, c’est s’affranchir de la maintenance contre une facture mensuelle. Faire tourner soi-même revient en général moins cher à grande échelle, quand la charge est stable ; mais alors chaque sauvegarde, chaque mise à jour, chaque panne est pour vous.
Sa façon de gérer une recherche filtrée. Dans la vraie vie, vous fouillez rarement tout d’un coup. Vous cherchez à l’intérieur des documents d’un seul client, ou seulement parmi les plus récents. Combiner ce genre de filtre avec une recherche par le sens est plus délicat qu’il n’y paraît : un filtre maladroit jette en silence de bons résultats. Les outils qui appliquent le filtre pendant la recherche, et non après, rendent des résultats bien plus fiables quand le filtrage est intense ; c’est ce qui devient le cas normal dès que de nombreux clients partagent un même système.
La quantité de surveillance qu’il réclame. Sauvegardes, copies de secours, contrôle des accès, supervision : un service loué vous décharge de l’essentiel, tandis que faire tourner le vôtre suppose de tout construire. C’est le coût qui n’apparaît jamais sur la facture.
Les six options
pgvector : celle que vous avez peut-être déjà
Le dépôt GitHub de pgvector
pgvector n’est pas du tout une base de données à part. C’est une extension pour PostgreSQL, la base de données passe-partout que des millions d’applications font déjà tourner. Vous l’activez, et votre base existante gagne la recherche par le sens, en plus de tout ce qu’elle sait déjà faire. Vos documents restent au même endroit, sauvegardés par le même procédé, interrogés par les mêmes requêtes ; et vous pouvez combiner une recherche par le sens avec un filtre ordinaire (« ce client seulement, comptes actifs seulement ») en une seule requête. Pour des données que vous possédez déjà, c’est l’option qui donne le moins de raisons d’ajouter quoi que ce soit de neuf. Elle a tout de même un plafond : à très grande échelle, ou quand un trafic de recherche soutenu se met à concurrencer le travail normal de votre application, un moteur conçu pour ça prend l’avantage. La plupart des projets n’atteignent jamais ce plafond.
Pinecone : on loue, on oublie
Capture d’écran du site de Pinecone
Pinecone s’adresse aux équipes qui veulent que le stockage soit le problème de quelqu’un d’autre. Rien à installer, rien à entretenir : vous l’appelez via une interface, et il monte en charge tout seul. Ce confort, c’est tout l’argument, et les contreparties en découlent. Vous ne pouvez pas faire tourner Pinecone sur votre propre matériel, ce qui l’exclut partout où les données doivent rester en interne pour des raisons légales ou de sécurité ; et à grande échelle avec une charge stable, vous payez plus cher que si vous exploitiez le vôtre. C’est l’option qui demande le moins d’efforts ici, et vous le payez en argent et en contrôle.
Qdrant : la valeur sûre à faire tourner soi-même
Capture d’écran du site de Qdrant
Qdrant est pensé pour être installé et exploité par vos soins, avec une version hébergée payante quand vous préférez vous en passer. Sa force, c’est précisément la recherche filtrée décrite plus haut : il applique vos filtres pendant la recherche, si bien que les résultats tiennent même lorsque presque chaque requête se limite à un seul client. Pour une équipe qui veut faire tourner son propre moteur de recherche dédié, Qdrant est le choix par défaut sans mauvaise surprise : rapide, prévisible, peu exigeant à l’exploitation. Il s’attache à bien faire un seul métier plutôt qu’à empiler des fonctions en plus ; pour la plupart des équipes, c’est justement ce qu’on attend.
Weaviate : quand les mots exacts comptent encore
Capture d’écran du site de Weaviate
La recherche par le sens a un angle mort : les références produit, les noms propres, les acronymes, là où c’est la chaîne de caractères exacte qui compte et où « proche par le sens » ne sert à rien. La signature de Weaviate, c’est la recherche hybride, qui marie la recherche par le sens et la bonne vieille recherche par mot-clé exact, pour que les deux formes de pertinence pèsent. Si votre contenu déborde de numéros de modèle ou de noms propres qui doivent correspondre au caractère près, cette combinaison est un avantage réel. La contrepartie : un système plus gros, avec davantage de concepts à apprendre quand vous l’exploitez vous-même.
Milvus : taillé pour la très grande échelle
Capture d’écran du site de Milvus
Milvus est conçu pour des collections qui se comptent en milliards d’éléments, l’échelle d’un grand groupe qui veut standardiser un seul système de recherche sur de nombreux produits. Il découpe son travail en couches indépendantes, pour que chacune grandisse de son côté. Cette puissance est aussi son piège : le faire tourner soi-même, c’est exploiter un véritable système réparti sur plusieurs machines, démesuré en dessous de l’échelle qu’il vise. Ses créateurs proposent une version hébergée, Zilliz Cloud, qui vous donne l’échelle sans avoir à gérer la grappe de serveurs vous-même. Ne vous tournez vers Milvus que lorsque vous avez vraiment dépassé ce qu’une seule machine peut encaisser. En dessous, des options plus simples vous serviront mieux pour moins cher.
Chroma : pour le premier prototype
Capture d’écran du site de Chroma
Chroma existe pour vous amener de zéro à une démo qui marche en quelques minutes. C’est le choix naturel tant que vous en êtes encore à expérimenter, sur votre portable ou dans un notebook (ces carnets de code interactifs qu’on utilise pour bricoler). Il a gagné en fonctions de production au fil du temps, mais la plupart des équipes le choisissent justement parce qu’elles débutent. Démarrez sur Chroma pour prototyper, puis planifiez le passage à un moteur plus solide délibérément, avant que le vrai trafic ne vous force la main.
En un coup d’œil
| Outil | Comment on l’utilise | Idéal pour | Limite principale |
|---|---|---|---|
| pgvector | Extension d’une base PostgreSQL que vous faites déjà tourner | Équipes déjà sous Postgres, échelle faible à moyenne | Atteint un plafond à très grande échelle et fort trafic |
| Pinecone | Service loué, rien à entretenir | Livrer vite sans aucune maintenance | Pas d’auto-hébergement ; plus cher à grande échelle |
| Qdrant | À faire tourner soi-même, version hébergée disponible | Recherche auto-hébergée avec filtrage intense | Moteur focalisé, moins de fonctions livrées d’office |
| Weaviate | À faire tourner soi-même, version hébergée disponible | Contenu où les mots-clés exacts doivent correspondre | Système plus gros à apprendre et exploiter |
| Milvus / Zilliz Cloud | Système réparti auto-hébergé, ou hébergé | Milliards d’éléments, standard à l’échelle d’un groupe | Lourd à exploiter ; démesuré sous la très grande échelle |
| Chroma | Tourne sur votre machine ou en petit serveur | Prototypes et premières expérimentations | Planifiez la migration avant l’arrivée du trafic de production |
Les prix bougent sans arrêt : le tableau reste volontairement général. L’économie qui dure, elle, est structurelle. Un service loué échange une facture récurrente contre une maintenance quasi nulle. Faire tourner soi-même un logiciel open source revient en général moins cher à grande échelle avec une charge stable, mais coûte du temps d’ingénieur. Et ajouter la recherche par le sens à une base que vous exploitez déjà est d’ordinaire le plus économique de tous, parce que ça n’ajoute aucun nouveau système à votre facture.
Comment choisir
Si vos données vivent déjà dans PostgreSQL et que vous comptez jusqu’à quelques millions d’éléments, commencez par pgvector. C’est le chemin le plus simple, et souvent le dernier dont vous aurez besoin. Si vous voulez un moteur dédié que vous exploitez vous-même, prenez Qdrant pour son équilibre entre vitesse, filtrage fiable et faible entretien. Si vous voulez zéro maintenance et que vous êtes prêt à payer pour ça, prenez Pinecone, en acceptant de ne pas pouvoir l’héberger en interne. Choisissez Weaviate quand la correspondance exacte des mots-clés est centrale, Milvus (ou sa version hébergée Zilliz Cloud) uniquement à la vraie échelle du milliard d’éléments, et Chroma pour les premiers prototypes.
L’erreur à éviter, c’est de voir trop grand : prenez le plus petit système qui couvre vos vrais besoins d’aujourd’hui, et laissez les limites réelles, pas les benchmarks, vous dire quand passer à l’étage au-dessus.
Et avant tout cela, il vaut la peine de se demander si vous avez besoin d’une base de données vectorielle tout court. Si vous hésitez à graver plutôt votre savoir directement dans le modèle d’IA lui-même, c’est une autre décision, que nous traitons dans notre guide pratique du fine-tuning face au retrieval ; la plupart des équipes qui se tournent vers le fine-tuning veulent en réalité du retrieval, exactement ce que fournissent ces outils.
Laquelle choisir, en un coup d’œil
FAQ
Ai-je besoin d’une base de données vectorielle dédiée, ou pgvector suffit-il ?
Jusqu’à quelques millions d’éléments, surtout quand vos données vivent déjà dans PostgreSQL, pgvector suffit en général et garde tout dans un seul système que vous exploitez déjà. Vous pouvez combiner une recherche par le sens avec des filtres ordinaires en une seule requête, et vos documents sont sauvegardés et sécurisés exactement comme le reste de vos données. Ne passez à un moteur dédié que lorsque vous atteignez une très grande échelle ou que vous avez besoin de fonctions que pgvector n’offre pas.
Vaut-il mieux louer un service géré ou faire tourner le sien ?
Louer (Pinecone, ou les versions hébergées de Qdrant, Weaviate et Milvus) échange un coût récurrent contre une maintenance quasi nulle ; c’est le bon choix quand le temps d’ingénieur est plus rare que le budget, ou quand vous devez livrer vite. Faire tourner soi-même un moteur open source revient en général moins cher à grande échelle avec une charge stable et vous donne le plein contrôle, y compris garder les données entièrement en interne ; mais c’est vous qui portez les sauvegardes, la montée en charge et les mises à jour.
Quelle option est la moins chère à petite échelle ?
Le plus souvent pgvector, parce qu’elle n’ajoute aucun nouveau service à votre pile technique. Si vous payez déjà PostgreSQL, la recherche par le sens voyage avec, à un coût supplémentaire minime. Parmi les options dédiées, faire tourner un moteur open source sur une petite machine coûte peu d’argent mais réclame de l’attention, tandis que plusieurs éditeurs proposent des paliers gratuits de démarrage qui couvrent les premiers développements avant que la facturation à l’usage ne s’enclenche.
Lesquelles gèrent la recherche par mot-clé exact en plus du sens ?
Ce mélange s’appelle la recherche hybride, et il compte quand des références produit, des noms et des acronymes doivent correspondre au caractère près, à côté du sens. Weaviate en a la version la plus aboutie, Qdrant la prend en charge, et Milvus la propose aussi. Si votre contenu déborde de chaînes de caractères qui doivent correspondre exactement, privilégiez un outil qui fait bien ce travail.
Les options open source sont-elles prêtes pour la production ?
Oui. Qdrant, Weaviate et Milvus encaissent tous de vraies charges de production, chacun avec une version hébergée du même éditeur si vous préférez ne pas les exploiter vous-même. Chroma est open source aussi, mais il vaut mieux le traiter comme un point de départ pour prototyper, avec une migration planifiée dès que le trafic de production arrive. Quant à pgvector, en tant qu’extension de PostgreSQL, il hérite de la maturité de PostgreSQL lui-même.
