Blog | Développeur | | 23 min de lecture

État des lieux des bases de données vectorielles – 2e trimestre 2026

Graphique illustrant l'évolution du marché des bases de données vectorielles

Résumé

  • Le marché des bases de données vectorielles est en train de se fragmenter en fonction de la taille, de charge de travail et déploiement que de disparaître.
  • Postgres est capable de gérer de nombreuses charges de travail vectorielles de petite envergure, tandis que les moteurs spécialement conçus à cet effet restent plus performants à grande échelle.
  • L'IA agentique réoriente les opérations de récupération vers des modèles à forte intensité d'écriture, faible latence et à mémoire hybride.
  • Pinecone Nexus montre comment les fournisseurs vont au-delà des fonctionnalités RAG de base, mais ses affirmations en matière de performances doivent encore faire l'objet d'une validation indépendante.
  • La décision clé consiste à adapter l'architecture de recherche à la charge de travail de traiter tous cas d'usage de l'IA cas d'usage même cas d'usage .

La dynamique affichée par Qdrant en 2026 montre que le marché des bases de données vectorielles est en train de se fragmenter plutôt que de disparaître.

En 2025, Ashutosh Kulkarni, PDG d’Elastic, a déclaré : «Les bases de données vectorielles sont une fonctionnalité. Elles ne constitueront jamais une activité à part entière. »Le 12 mars 2026, Qdrant a levé 50 millions de dollars lors d’un tour de table de série B, a franchi la barre des 250 millions de téléchargements et a lancé la version 1.17. En juin 2026, le projet comptait 32 400 étoiles sur GitHub, contre 27 000 en décembre 2025. Research and Markets prévoit que le marché des bases de données vectorielles passera de 3,73 milliards de dollars en 2026 à 10,6 milliards de dollars d’ici 2032, avec un TCAC de 23,5 %. Un secteur en déclin ne génère pas de tels chiffres.

Principaux indicateurs de l'aperçu trimestriel

Aperçu de la croissance par trimestre

Ashutosh a évoqué une réelle pression sur les ressources, mais uniquement pour une partie du marché. PostgreSQL, grâce à pgvector, prend désormais en charge les charges de travail inférieures à 50 millions de vecteurs et réduit le coût total de possession (TCO) de 40 à 60 %. Les index HNSW (Hierarchical Navigable Small World) et IVFFlat (Inverted File Flat) permettent la recherche par « voisin le plus proche approximatif » (ANN), tandis que PostgreSQL conserve la conformité ACID que les bases de données vectorielles natives n’offrent pas. La combinaison de la recherche par mot-clé et de la similarité vectorielle au sein de la base de données dans un seul et même système élimine le besoin d’un magasin vectoriel séparé. C’est ce segment de marché que l’argumentation d’Ashutosh cible avec précision.

Au-delà de 50 millions de vecteurs, les écarts de performances deviennent perceptibles. pgvector stocke les représentations directement dans les tables PostgreSQL. Un jeu de données 1 million de vecteurs (à 1 536 dimensions) occupe environ 6 Go rien que pour les vecteurs, l’indexation HNSW ajoutant 3 à 4 Go supplémentaires avec les paramètres par défaut. Le temps de création de l’index augmente à chaque nouvelle charge de travail, et la latence passe de 50 ms à 800 ms une fois le seuil des 10 millions d’embeddings dépassé sur une instance dotée de 1 To de RAM.

Les charges de travail de l'ordre du milliard mettent en évidence ce que les bases de données relationnelles ne peuvent pas prendre en charge sans reconfiguration continue, quantification et indexation sur disque. TripAdvisor indexe plus d'un milliard utilisateur multimodaux sur Qdrant. HubSpot utilise Qdrant pour son assistant IA Breeze. Une base de données polyvalente dotée d'un type de données vectoriel peine à fonctionner à cette échelle.

Le scénario de « décès » et la croissance de la catégorie des bases de données vectorielles sont valables au deuxième trimestre 2026, mais ils définissent des segments différents d’un même marché. Votre position sur l’échelle « charge de travail » et déploiement détermine quel argument s’applique à vos décisions en matière d’infrastructure ce trimestre.

base de données du marché, évolution du marché

Le marché des bases de données vectorielles est en pleine croissance. La question est de savoir quel segment chaque fournisseur est en mesure de desservir.

La thèse de la trifurcation : un marché qui se divise en trois

Le marché des bases de données vectorielles ne se réduit pas à un seul leader. On observe trois segments distincts, liés respectivement à la taille, charge de travail et à déploiement . La plupart des choix architecturaux effectués en 2026 aboutissent à des résultats erronés, car les équipes se basent uniquement sur le nombre de vecteurs.

trifurcation du marché

Le marché des bases de données vectorielles se divise en trois segments selon l'échelle, charge de travail et déploiement

Évolutivité : les points forts et les limites de Postgres

Tous les grands fournisseurs de cloud hyperscale et toutes les bases de données relationnelles traditionnelles proposent désormais une recherche vectorielle pure. PostgreSQL dispose de pgvector et pgvectorscale, Oracle propose Database 26ai, Microsoft SQL Server a ajouté un type de données vectoriel, Amazon RDS utilise pgvector, et Cloud SQL for MySQL de Google intègre une recherche par similarité. Les enquêtes annuelles menées par Stack Overflow auprès des développeurs montrent que PostgreSQL a occupé la première place parmi les bases de données de 2023 à 2025.

Pour les ensembles de vecteurs de moins de 50 millions, Postgres, associé à pgvector et pgvectorscale, prend en charge les charges de travail en production sans nécessiter de moteur vectoriel distinct. Pour les équipes qui utilisent déjà Postgres, l'ajout de la recherche vectorielle avec pgvector se résume à une seule commande : `CREATE EXTENSION vector;`. TigerData a comparé les performances de pgvectorscale à celles de Qdrant sur le jeu de données Cohere Wikipedia de 50 millions d’entrées (768 dimensions), en visant un taux de rappel de 99 % sur une instance AWS r6id.4xlarge. pgvectorscale a affiché un débit de 471,57 requêtes par seconde (QPS) contre 41,47 QPS pour Qdrant, soit un débit 11 fois supérieur dans une configuration à nœud unique.

Postgres s'est imposé en termes de débit, mais Qdrant l'a emporté sur la latence p95 avec 36,73 ms contre 60,42 ms pour pgvectorscale, ainsi que sur le temps de création d'index avec 3,3 heures contre 11,1 heures. Comme le souligne Desmond Tan, notre vice-président de l'ingénierie :

À l'échelle d'un milliard de vecteurs et avec des contraintes strictes en matière de latence, une base de données polyvalente à laquelle on ajoute simplement un type vectoriel ne fait pas le poids. La difficulté n'a jamais résidé dans la recherche du plus proche voisin, mais dans les contraintes opérationnelles, telles que la stabilité du taux de rappel en cas de mises à jour continues.

Des moteurs spécialement conçus accélèrent la création d’index, gèrent le partitionnement entre les nœuds, assurent le déchargement sur disque et maintiennent une latence p95 prévisible lors des écritures simultanées exigées par des charges de travail vectorielles de plus de 100 millions. NVIDIA a développé un exploration de données multimodale sur Milvus, indexant plus de 10 milliards de points de données de capteurs provenant de flottes de test, et a réduit les coûts de 30 fois sans avoir à repenser l’architecture. Lorsque vous réglez les paramètres autovacuum et maintenance_work_mem pour maintenir un taux de rappel stable, votre charge de travail déjà dépassé celle de Postgres avec pgvector.

charge de travail: les agents d'IA ont remis en cause l'hypothèse d'une optimisation pour la lecture

Des bases de données vectorielles dédiées ont été créées pour les pipelines RAG (Retrieval-Augmented Generation) à forte intensité de lecture. En 2026, les agents IA émettent 10 fois plus de requêtes que les humains. Ils effectuent des écritures fréquentes, ce qui entraîne un gonflement des index, des pics de trafic et une pression liée à la multi-location que les index optimisés pour la lecture ne parviennent pas à gérer correctement. Comme l’a publié sur X un ingénieur backend d’eToro,

En 2026, la question n'est plus de savoir quelle base de données vectorielle choisir, mais quelle stratégie de récupération correspond charge de travail aux besoins de la charge de travail . La plupart des défaillances en production proviennent du fait de vouloir appliquer systématiquement à chaque problème le même pipeline simpliste consistant à « récupérer puis générer ».

Les bases de données vectorielles « cloud-first » répondent aux charges de travail à forte intensité d'écriture grâce à la mise à l'échelle automatique, à isolement native au niveau des lignes et streaming en temps réel. Mais le marché s'interroge également sur la pertinence même d'héberger ces bases de données dans le cloud.

déploiement: les défis que les principaux fournisseurs de solutions cloud-native ne parviennent pas à relever

Pour les secteurs traitant des données sensibles, les représentations vectorielles doivent respecter des normes de conformité strictes en vertu de lois telles que la loi européenne sur l’IA, le CLOUD Act américain, le Règlement général sur la protection des données (RGPD) et la loi HIPAA (Health Insurance Portability and Accountability Act). Gartner prévoit que d’ici 2030, plus de 75 % des entreprises européennes et du Moyen-Orient rapatrieront leurs charges de travail virtuelles en raison des risques géopolitiques, contre moins de 5 % en 2025. Les fournisseurs de cloud fournissent des certificats de conformité, mais le fait de conserver la base de données sur site aux équipes sur site un contrôle direct sur gouvernance des données gouvernance réduit les points de défaillance uniques introduits par l’infrastructure cloud.

Le choix de l'infrastructure adaptée au deuxième trimestre 2026 dépend du nombre de vecteurs, de l'adéquation opérationnelle et déploiement . Ce tableau vous aide à prendre votre décision.

Dimension  Utilisez pgvector si  Utilisez un moteur vectoriel spécialement conçu à cet effet si
Nombre de vecteurs  < 50M vectors > 50 millions de vecteurs
Complexité du filtrage  C'est simple : PostgreSQL gère les clauses WHERE et la recherche hybride grâce à BM25 et aux vecteurs denses.  Moyen ; métadonnées par charge utile, scalaire ou métadonnées avec des conditions imbriquées 
Exigences en matière de multi-locataires  Un schéma par locataire ; c'est vous qui mettez en place et assurez le respect de isolement  isolement stricte par locataire isolement des espaces de noms, des partitions ou des collections 
déploiement  Moteur PostgreSQL existant, sur site SaaS géré, Kubernetes ou Docker auto-hébergé
Tolérance à la complexité opérationnelle  Faible ; l'équipe dispose d'une expertise en Postgres De faible à élevé, en fonction déploiement ; opérations gérées pour les moteurs basés sur le cloud ; expertise DevOps pour les bases de données vectorielles auto-hébergées 

Pinecone : Le paradoxe du quart

Pinecone présente Nexus comme l'architecture d'agents destinée à remplacer RAG, en s'appuyant sur un seul test de performance interne que personne n'a encore réussi à reproduire. C'est ce test non vérifié, et non le lancement en lui-même, qui déterminera si Nexus a sa place dans votre infrastructure d'agents ce trimestre.

Le chiffre d'affaires de Pinecone est passé de 27 millions de dollars en 2024 à 14 millions de dollars en 2025; Notion a connu un taux de désabonnement élevé, et The Information a rapporté en août 2025 que l'entreprise envisageait une cession. Neuf mois plus tard, le 4 mai 2026, l’entreprise a lancé Nexus, son produit le plus ambitieux à ce jour. Si vous exécutez des charges de travail vectorielles sur Pinecone, c’est dans ce contexte que vous devez évaluer Nexus.

Avec Nexus, Pinecone tente de progresser dans la pile de l’IA agentique. Cette solution combine un compilateur de contexte, qui génère des artefacts vectoriels tâche à partir d’informations brutes issues d’une base de données vectorielle, et un moteur de recherche modulable qui fournit ces artefacts accompagnés de citations champ par champ et d’une résolution déterministe des conflits. Ash Ashutosh, PDG de Pinecone, a qualifié ce lancement de « changement architectural » :

RAG a été conçu pour des utilisateurs humains. Nexus a été conçu pour des utilisateurs « agents », car leur langage est très différent.

KnowQL, un requête déclaratif, a suivi la sortie de Nexus. Il permet aux agents d’IA de spécifier l’intention, la provenance, le format de sortie, les budgets de latence et les exigences de confiance sans avoir à interpréter directement les vecteurs bruts. Le benchmark interne de Pinecone sur les déclarations SEC 10-K a fait état d’une augmentation des taux de réussite passant de 50 à 60 % à plus de 90 %, d’une réduction de 95 % de l’utilisation de tokens par les grands modèles linguistiques (LLM) et d’une multiplication par 30 de la vitesse tâche . Aucun de ces résultats n’a été validé dans le cadre de déploiements en production.

Le mécanisme de Nexus, qui consiste à compiler le raisonnement avant requête toute requête et à stocker les résultats sous forme d'artefacts réutilisables, va dans la bonne direction. Arun Chandrasekaran, vice-président et analyste chez Gartner, l'a décrit comme une avancée significative par rapport à la simple recherche : «Contrairement au RAG traditionnel, qui repose sur une recherche purement sémantique au moment de l’exécution, la compilation architecturale intègre une logique structurelle dans la métadonnées , ce qui peut réduire le temps de réponse et offrir un meilleur raisonnement.» Janakiram MSV conteste spécifiquement KnowQL, en faisant valoir que « KnowQL doit franchir le cap de la normalisation que SQL a déjà franchi, et les normes ne sont pas promulguées par un seul fournisseur.» 

Desmond reconnaît que le principe de Nexus est valable mais pas nouveau, le qualifiant de « mise en cache appliquée à la récupération ». Concernant le benchmark à cas de test unique, il est catégorique : « Avant de recommander Nexus, j’aurais besoin d’une reproduction indépendante sur une suite de tests non triée sur le volet, d’une explication claire du mode de défaillance lié aux artefacts périmés et d’une évaluation honnête du risque de dépendance. » Il ne souhaite pas y consacrer d’infrastructure d’agents ce trimestre, car « KnowQL est un requête propre à un seul fournisseur, tandis que le SQL est devenu une norme grâce à un comité, et non par simple déclaration. »

Pinecone affirme que son moteur vectoriel est utilisé par 9 000 clients et 800 000 développeurs. L’entreprise a été pionnière dans le domaine des bases de données vectorielles gérées en 2023 et a atteint une valorisation de 750 millions de dollars après une levée de fonds de série B de 100 millions de dollars. Elle a fondé son message de lancement sur la technologie RAG, puis a lancé Nexus, un produit qui va au-delà de ce concept. Mais Nexus dépend toujours de la base de données vectorielle de Pinecone pour la vitesse de recherche, le stockage et l’évolutivité. Ash a confirmé que « les vecteurs sont toujours stockés et gérés par la base de données vectorielle de Pinecone ». L’argument avancé par le marché selon lequel l’infrastructure de l’ère RAG est obsolète ne tient pas la route tant que les systèmes agentiques continuent de s’appuyer sur elle. 

Cette information n'est pas encore confirmée, et les gains observés sur les indices de référence n'ont pas été validés. Mais vous maîtrisez votre pipeline d'intégration, quoi qu'il arrive par la suite. Documentez dès aujourd'hui le modèle, la version, les dimensions et la stratégie de découpage. Veillez à ce que votre infrastructure de récupération reste portable, afin que la couche de compilation reste une optimisation facultative que vous pouvez remplacer.

Les bases de données vectorielles constituent-elles le support adéquat pour la mémoire des agents ?

Les bases de données vectorielles gèrent bien un type de mémoire d'agent, mais présentent des limites pour l'autre. C'est en imposant un seul type d'index pour répondre à différents besoins de recherche que la plupart des architectures d'IA en production échouent.

La mémoire de l'agent exécute deux types de charges de travail distinctes. La recherche sémantique ponctuelle sur une bibliothèque de documents stable implique un volume important de lectures et est indexée par lots. Il s'agit du RAG, et les index HNSW et IVF le gèrent bien. La deuxième partie concerne la mémoire de travail de l'agent. Elle implique des écritures fréquentes, des recherches itératives, l'extraction de faits et la résolution d'entités. Un index optimisé pour la lecture perd en performance face à ce charge de travail.

Ben Bartholomew, de Hindsight, avait en partie raison lorsqu’il a déclaré : « “La mémoire d’agent équivaut à une base de données vectorielle” est devenu une sorte de lieu commun… La mémoire d’agent est tout autre chose, et c’est le fait de considérer ces deux concepts comme un seul et même problème qui a conduit, au départ, à ce mauvais paramètre par défaut. » Le tableau ci-dessous présente les différences entre requête RAG et requête d’agents selon cinq dimensions de recherche.

Critères requête RAG  requête d'agent 
Modèle d'accès Niveau de lecture élevé  Lecture/écriture 
Mode de recherche  One-shot Itérative 
Budget de latence >500 ms Moins de 200 ms par appel d'outil
Exigences en matière de fraîcheur  Indexation par lots  Streaming 
Type d'index HNSW/FIV  Optimisé pour l'écriture ou hybride 

En mai 2025, Anthropic a supprimé la recherche vectorielle de Claude Code pour la remplacer par grep. Cursor, Windsurf, Cline, Devin et Sourcegraph Amp ont emboîté le pas, abandonnant la similarité vectorielle au profit d'une recherche pilotée par des outils.

L'équipe produit de Weaviate a passé deux semaines à intégrer Engram, son produit de mémoire basé sur des vecteurs, à Claude Code via le Model Context Protocol (MCP). Claude n'en a absolument pas tenu compte, expliquant : «Je me rabats par défaut sur MEMORY.md par défaut, car il est toujours chargé : latence nulle, aucun appel d’outil, contexte garanti. Il n’y a aucune raison de recourir à un outil externe lorsque le magasin de mémoire principal est déjà présent. » Un agent de codage parcourt un graphe de dépendances, d’importations, d’appels de fonctions et de définitions de types. Cette charge de travail du déterminisme et des correspondances exactes, plutôt qu’une similitude sémantique. 

L'équipe Hindsight utilise une approche multi-stratégies qui combine et classe quatre moteurs de recherche parallèles sur PostgreSQL : la recherche sémantique, la recherche basée sur les entités, le filtrage temporel et la traversée de graphes. Sur le benchmark LongMemEval, cette approche hybride a atteint une précision de 94,6 % , contre 49 % pour le système de Mem0, qui repose principalement sur les vecteurs. La recherche par grep et la recherche hybride offrent de meilleurs résultats que la recherche vectorielle pure pour les agents de codage et les collections de documents fréquemment mises à jour de moins de 10 millions d'entrées . Maintenir un index vectoriel synchronisé avec une base de code active nécessite des ré-incorporations fréquentes, ce qui est coûteux à grande échelle et retarde l'actualité des résultats de recherche.

L'argument avancé par Hindsight est qu'une base de données vectorielle ne dispose pas de la perception temporelle, de la séparation des préoccupations et des capacités de résolution des conflits requises par la mémoire d'un agent en activité. Le problème réside dans le fait d'appliquer la recherche vectorielle à une contrainte d'agent inadaptée.

Herbie Turner, directeur technique (CTO) de &AI, a confirmé que Qdrant constituait « la référence absolue » pour leur agent de brevets traitant plus d’un milliard de vecteurs. Reddit continue d’exploiter des données vectorielles à l’échelle du milliard sur Milvus. frameworks de mémoire IA frameworks Mem0 utilisent des bases de données vectorielles comme infrastructure de recherche sous-jacente, associées à un graphe de connaissances pour les relations entre entités. Les bases de données vectorielles conservent les faits de domaine à long terme d’une session à l’autre. Pour les bases de connaissances volumineuses et hétérogènes, où la précision de la recherche détermine les résultats commerciaux et où les résultats manqués coûtent cher, la recherche vectorielle reste la bonne approche. C’est également la stratégie de recherche la plus pratique pour les requêtes en langage naturel dans les systèmes de recherche de documents non structurés.

André Zayarni, PDG de Qdrant, a expliqué l'écart entre requête qui justifie l'intérêt des bases de données vectorielles :

Les humains effectuent quelques requêtes toutes les quelques minutes. Les agents, quant à eux, en effectuent des centaines, voire des milliers par seconde, simplement pour recueillir des informations leur permettant de prendre des décisions.

Les agents gaspillent jusqu’à 85 % de la puissance de calcul à la reconstitution du contexte. Les bases de données vectorielles permettent d'effectuer cette récupération rapidement et avec précision, même à grande échelle.

architecture mémoire d'agent

Mémoire à trois couches d'agents

Les agents de codage et l'état de travail modifiable relèvent du grep, mais la recherche vectorielle reste l'infrastructure la plus adaptée à la recherche de connaissances à grande échelle.

déploiement que la catégorie a oublié

La plupart des comparaisons de bases de données vectorielles publiées au premier trimestre 2026 partent du principe d’une connectivité cloud permanente. Cette hypothèse exclut les sites de production, les réseaux hospitaliers, les systèmes de défense en « air gap » et tout environnement où les données ne peuvent pas quitter le bâtiment. Trois facteurs rendent désormais cette lacune impossible à ignorer. Notre directrice technique, Emma McGrattan, explique comment le secteur en est arrivé là : « La première vague de développement des bases de données vectorielles a été portée par des équipes d’IA natives du cloud (chercheurs, start-ups, laboratoires d’hyperscalers) travaillant dans des environnements où les données pouvaient circuler librement et où la connectivité était considérée comme acquise. »

Rapatriement des services cloud pour l'IA d'entreprise

86 % des DSI prévoyaient de transférer leurs charges de travail liées à l'IA hors du cloud public d'ici 2025, en raison des coûts liés au cloud, des réglementations en matière de souveraineté des données, des exigences de latence et enfermement propriétaire. Le rapport « State of the Cloud » 2026 de Flexera révèle que 23 % d'entre eux ont déjà mené à bien cette migration. Les fournisseurs de bases de données axés sur le cloud emboîtent le pas aux entreprises et reviennent sur site.

Amazon a lancé RDS sur Outposts pour déploiement sur site en colocation. Oracle a commercialisé Database 26ai plateformes janvier 2026 pourdéploiement sur site sur plateformes Linux x86-64. Chacune de ces lancements constituait une réponse directe à la tendance des entreprises à rapatrier leurs charges de travail au sein de leur propre infrastructure. Desmond prévoit qu’au second semestre 2026, « la question de savoir si la base de données vectorielle peut fonctionner en interne cessera d’être une simple case à cocher pour devenir le principal critère de sélection. Les fournisseurs cloud-native ne peuvent pas s’adapter à cela a posteriori ; c’est une question d’architecture. » 

Souveraineté des données

Le RGPD interdit la sortie des données à caractère personnel hors de l'Espace économique européen (EEE). Les transferts de données hors de l'EEE nécessitent le recours aux clauses contractuelles types (SCC) de la Commission européenne, le chiffrement des données au repos et en transit, des contrôles d'accès basés sur les rôles, ainsi qu'une analyse d'impact documentée relative au transfert.

La loi HIPAA impose des mesures de sécurité techniques pour les informations de santé protégées (PHI) sous forme électronique. La loi européenne sur l’IA, qui entrera en vigueur le 2 août 2026, exige gouvernance documentée des données, avec des amendes pouvant atteindre 35 millions d’euros ou 7 % du chiffre d’affaires mondial annuel pour les systèmes d’IA à haut risque. Aucune de ces lois n’impose explicitement la résidence des données, mais celles-ci doivent respecter les législations locales quel que soit leur lieu de stockage. C’est pourquoi 95 % des cadres supérieurs considèrent désormais l’IA souveraine comme une priorité essentielle à la mission de leur entreprise. Conserver les données au sein de votre périmètre de sécurité constitue la voie la plus pratique vers la conformité. Comme l’a fait remarquer Emma, « intégrer a posteriori la souveraineté et gouvernance des systèmes qui n’ont pas été conçus à cet effet est coûteux, lent et souvent incomplet. »

Physique

La latence réseau n'est pas un problème de configuration. Même au sein d'une même région cloud, le temps aller-retour ajoute 20 à 80 ms avant que tout calcul ne commence. Si l'on ajoute à cela le temps de traitement de l'application, la latence liée à l'intégration du modèle et le délai de propagation, la recherche vectorielle dans le cloud introduit un seuil de latence que aucune optimisation ne permet d'éliminer.

Comme l'a déclaré Emma,

Même une recherche vectorielle dans le cloud parfaitement optimisée, qui renvoie des résultats en 20 ms, reste quatre fois trop lente pour la détection de défauts dans le secteur industriel ou la classification véhicule autonome . Si vous avez besoin d’un temps de réponse inférieur à 5 ms, le cloud est hors de question, quelles que soient les autres considérations. Les lois physiques régissant le temps de transit aller-retour sur un réseau sont immuables.

L'Asan Medical Center (AMC) a déployé le premier système privé de recherche de connaissances dédié au traitement de la septicémie en Corée, fonctionnant entièrement sur les sur site de l'hôpital au sein d'un réseau fermé. Ce système fournit plus rapidement des tests de diagnostic de la septicémie et des recommandations en matière d'antibiothérapie, tout en conservant les données sensibles des patients au sein même de l'établissement. L'AMC illustre bien les contraintes matérielles déploiement tout déploiement en périphérie.

Les appareils disposant de moins de 4 Go de stockage peuvent gérer entre 10 000 et 1 million de vecteurs sans élagage ni hiérarchisation. Les moteurs natifs du cloud ont été dimensionnés en fonction des budgets de mémoire vive du cloud, mais cette hypothèse ne tient pas sur le matériel en périphérie.

contraintes du département

déploiement par secteur d'activité et par environnement

Le tableau ci-dessous présente ces contraintes selon déploiement : cloud, sur site et en périphérie.

déploiement Seuil de latence  Nombre maximal de vecteurs  Exigences en matière de connectivité  Conformité en matière de souveraineté  Modèle opérationnel Modèle de coûts type
Cloud  50 à 500 ms Plus de 100 millions de vecteurs Toujours obligatoire  Options de cloud régional ; les données peuvent traverser les frontières SaaS géré ; la maintenance est assurée par le fournisseur Facturation à l'utilisation ; les frais comprennent les frais requête, de stockage et de sortie de données
Sur site Moins de 20 ms  10 à 50 millions de vecteurs, sous réserve des contraintes matérielles  Connexion intermittente  Contrôle total ; les données restent sur site  Autogestion ; l'équipe se charge des opérations et de la maintenance du matériel  Dépenses d'investissement et charges d'exploitation 
Bord Moins de 5 ms  Vecteurs de 10 000 à 1 million ; limités par la mémoire et le matériel  Hors ligne ; fonctionne entièrement hors ligne  Les données ne quittent jamais l'appareil  Binaire Embarqué déployé ; maintenance courante minimale  Achat ponctuel d'une licence ou de matériel

déploiement dans le cloud déploiement la solution la plus simple pour plus de 100 millions de charges de travail nécessitant une latence inférieure à 100 ms et une connectivité permanente.

Les charges de travail soumises à une connectivité intermittente et exigeant une latence inférieure à 5 ms ainsi qu’un traitement local des données nécessitentdéploiement en périphérie ou sur site . Comme l’a souligné Emma, « L’écosystème des bases de données vectorielles open source, bien qu’excellent pour les déploiements dans le cloud, n’est tout simplement pas optimisé pour les contraintes qui comptent à la périphérie : empreinte mémoire limitée, connectivité intermittente, optimisation des performances spécifique au matériel, latence locale prévisible et capacité à fonctionner entièrement en mode air-gapped. » Même les fournisseurs qui s’orientent vers des modèles hybrides n’ont pas comblé cette lacune. Zilliz Cloud a lancé « Bring Your Own Cloud Infrastructure » (BYOC-I) en avril 2025, mais cette solution nécessite toujours un accès au cloud.

Avant de choisir un déploiement , répondez à ces trois questions :

  1. Quel est votre modèle de connectivité ?
  2. Votre charge de travail une latence inférieure à 5 ms ?
  3. Y a-t-il une exigence en matière de localisation des données ou de « air gap » ?

Si une réponse exclut une connectivité réseau permanente, les fournisseurs de solutions cloud natives ne pourront pas prendre en charge votre charge de travail. Actian VectorAI DB est spécialement conçu pour faire face aux contraintes réseau. VectorAI DB fonctionne sur NVIDIA Jetson, Raspberry Pi, des serveurs industriels en périphérie, des centres de données hospitaliers et des installations en mode « air-gap ». Il offre un débit de 1 040 QPS pour 1 million de vecteurs, avec une latence p99 de 12,7 ms sur du matériel local. Il fonctionne entièrement hors ligne et se synchronise de manière optionnelle lorsque la connectivité est rétablie.

Benchmark Trust en 2026 : comment interpréter les chiffres

Les tests de performance réalisés par les éditeurs vous indiquent les performances d'une base de données dans les conditions de test choisies par ces derniers. Avant d'utiliser un chiffre pour prendre une décision concernant votre infrastructure au deuxième trimestre 2026, assurez-vous de bien comprendre ce qu'il mesure réellement.

Qdrant publie le benchmark « vector-db-benchmark », Weaviate est propriétaire des benchmarks « ANN-benchmarks », Zilliz Cloud est propriétaire de « VDBBench », TigerData a publié son benchmark « pgvectorscale » en utilisant un fork des benchmarks « ANN-benchmarks », et Redis publie ses propres suites de benchmarks.

La plupart des tests de performance évaluent des index prédéfinis, jeux de données statiques et des configurations de bases de données obsolètes. Aucune de ces conditions ne reflète les environnements de production ni les charges de travail des agents. La page dédiée aux tests de performance de Qdrant précise explicitement : « Sommes-nous partiaux ? Probablement, oui. » Dansune publication LinkedIn critiquant les résultats des tests de performance de TigerData, Qdranta ajouté : « Personne ne publie de benchmark dans lequel son produit ne brille pas. Nous faisons de même. » 

Le test comparatif entre pgvectorscale de TigerData et Qdrant a été réalisé sur jeu de données Cohere Wikipedia 50M (768 dimensions), jeu de données un objectif de rappel de 99 %, sur une instance AWS r6id.4xlarge. La configuration comprenait 16 vCPU, 128 Go de RAM et un SSD NVMe de 950 Go connecté localement. Avec requête inférieures à 100 ms, pgvectorscale a atteint 471,57 QPS contre 41,47 QPS pour Qdrant.  Qdrant s’est imposé en termes de temps de création d’index (3,3 heures contre 11,1 heures pour pgvectorscale), ainsi qu’en termes de latence de queue à un taux de rappel de 90 %, avec une latence p95 inférieure de 58,6 % et une latence p99 inférieure de 63,2 %.

Qdrant a fait valoir que le test ne reflétait pas les cas d'utilisation en production impliquant métadonnées , la recherche hybride avec des vecteurs clairsemés ou la recherche multi-vecteurs. L'entreprise a également indiqué que TigerData n'avait pas optimisé Qdrant pour sa propre architecture, alors que pgvectorscale utilisait StreamingDiskANN et la quantification binaire statistique (SBQ). L'écart de débit se réduit dès que l'une ou l'autre de ces conditions change.

La critique de Qdrant met précisément en évidence ce que la plupart des tests de performance des bases de données vectorielles négligent. VDBBench 1.0, développé par Zilliz Cloud, évalue ingestion de données continue ingestion de données, le débit de recherche, la dérive des performances sous des charges simultanées de lecture/écriture, ainsi que la sélectivité métadonnées . Ce sont là les conditions auxquelles votre système de production sera confronté.

Chaque chiffre de référence que vous utilisez doit d'abord répondre à ces cinq questions :

  1. Qui a publié cet indice de référence ?
  2. Sur quel matériel, avec quels paramètres d'index et simultanéité le test de performance a-t-il été effectué ?
  3. Quels indicateurs ont été retenus et lesquels ont été écartés ?
  4. La charge de travail -elle charge de travail votre cas d'usage?
  5. Ce test de référence est-il reproductible et a-t-il fait l'objet d'une vérification indépendante ?

Cinq questions pour évaluer les tests de performance des bases de données vectorielles

Cinq questions pour évaluer tout test de performance portant sur une base de données vectorielle

Comme le dit Desmond, « Si la capacité de mémoire, le matériel et simultanéité ne simultanéité pas tous précisés, ignorez ce chiffre ». Le benchmark le plus fiable est celui que vous effectuez sur vos propres données, votre propre matériel et vos propres requête . Si votre équipe exécute des charges de travail vectorielles sur Milvus, appliquez le correctif vers la version 2.5.27+ ou 2.6.10+ avant de comparer les résultats des benchmarks. Cela permet de corriger les vulnérabilités d’authentification CVE-2026-26190 (CVSS 9,8) et CVE-2025-64513 (CVSS 9,3).

La carte des idées de la communauté

Au deuxième trimestre 2026, le marché des bases de données vectorielles s'est stabilisé, avec des tendances claires en matière d'adoption, de tarification et d'adéquation aux cas d'utilisation.

Milvus arrive en tête des projets open source les plus populaires, avec plus de 44 000 étoiles sur GitHub, suivi de Qdrant (plus de 32 000), ChromaDB (plus de 28 000), Weaviate (plus de 16 000) et LanceDB (plus de 10 000).

étoiles GitHub

Le nombre d'étoiles reflète l'intérêt de la communauté, et non l'utilisation en production

LanceDB affiche le taux de croissance le plus élevé en termes de notoriété, passant de 6,7 % à 9,6 % d'une année sur l'autre après avoir levé 30 millions de dollars lors d'un tour de table de série A en juin 2025. ChromaDB a quant à lui reculé de 15,6 % à 13,4 % sur la même période, pgvector ayant attiré l'attention des équipes utilisant déjà Postgres.

évolution de la part d'attention

Évolution de la notoriété de LanceDB par rapport à Chroma

Weaviate, Milvus, Qdrant et LanceDB peuvent être hébergés gratuitement en mode auto-hébergé. Vous ne payez que la puissance de calcul que vous utilisez pour les faire fonctionner. C'est au niveau de leurs offres gérées que les coûts divergent.

Le 27 octobre 2025, Weaviate Cloud a remplacé son forfait « Serverless » à 25 $ par mois par un forfait « Flex » à 45 $ par mois, soit une augmentation de 80 %. Le forfait « Plus » coûte 280 $ par mois, et le forfait « Premium » 400 $ par mois. Chaque niveau comprend des frais supplémentaires liés à l'utilisation, qui couvrent les dimensions des vecteurs, le stockage et la durée de conservation des sauvegardes.

Zilliz Cloud propose une offre gratuite comprenant cinq collections, 5 Go de stockage et 2,5 millions de vCU par mois. Le forfait « Dedicated Standard » coûte 126 $ par mois en frais de calcul. Le forfait « Dedicated Enterprise » coûte 196,56 $ par mois, le stockage étant facturé à 0,025 $/Go et les frais de transfert de données étant facturés séparément.

L'offre gratuite de Qdrant Cloud comprend un cluster à nœud unique doté de 1 Go de RAM, de 0,5 vCPU et de 4 Go d'espace disque. L'offre Standard facture la puissance de calcul, la consommation de mémoire, le stockage de sauvegarde et les jetons d'inférence de modèles. L'offre Premium nécessite un entretien commercial direct. LanceDB Cloud propose un stockage d'objets à 0,02 $ par Go et par mois, tandis que la tarification Enterprise repose sur un engagement annuel personnalisé.

Pinecone a lancé le 6 mai 2026 une formule « Builder » à 20 dollars par mois, après avoir lancé en juillet 2025 une formule « Standard » à 50 dollars par mois. OpenMetal a indiqué que le prix de départ de 50 dollars passait à 380 dollars, puis à 2 847 dollars à mesure que l'utilisation augmentait. La formule « Enterprise » prévoit un forfait mensuel minimum de 500 dollars depuis juin 2026.

Le consensus sur les cas d’utilisation des principales bases de données vectorielles en 2026 dépend de l’échelle et des préférences opérationnelles. Pinecone élimine la charge opérationnelle pour les équipes qui souhaitent bénéficier d’une infrastructure gérée. pgvector s’adresse aux équipes Postgres gérant entre 10 et 50 millions de vecteurs. Milvus gère requête distribuées requête la gestion des shards pour déploiement à l’échelle du milliard. Weaviate convient aux applications nécessitant une recherche hybride native et des modèles d’embedding intégrés. Qdrant propose une recherche vectorielle modulable et des filtres basés sur JSON. ChromaDB couvre les prototypes RAG et les outils internes locaux. LanceDB est particulièrement adapté aux Embarqué et aux systèmes d’IA multimodaux.

base de données vectorielle, cas d'usage , carte cas d'usage

Base de données vectorielle cas d'usage carte cas d'usage pour le deuxième trimestre 2026

Le cadre décisionnel pour ce trimestre

Ces trois audits permettent de déterminer quelle base de données de vecteurs est la mieux adaptée à votre pile technologique. Effectuez-les dans l'ordre avant de choisir une infrastructure pour votre application ou votre agent.

Contrôle n° 1 : comptage des vecteurs

Le nombre de vecteurs que vous choisissez définit les limites de ce qui mérite d'être évalué.

  • <10M vectors on Postgres: Use pgvector. It keeps vector data adjacent to relational data without managing a new database engine. You get ACID transactions, hybrid search, and one security model in the same system. 
  • Vecteurs de 10 à 50 millions: Comparez les performances de Qdrant auto-hébergé et de pgvectorscale sur vos données avant de vous engager. Qdrant permet la recherche vectorielle avec un filtrage JSON basé sur la charge utile. pgvectorscale améliore les performances de pgvector à moyenne échelle grâce à StreamingDiskANN. 
  • >50 millions ou multi-locataires à l'échelle des agents: Utilisez l’architecture distribuée et accélérée par GPU de Milvus pour évoluer horizontalement ou créer un magasin vectoriel personnalisé calqué sur le comportement de votre agent. 

Audit n° 2 : déploiement

C'est l'environnement d'exécution de votre application qui détermine quelles bases de données restent viables. Si votre charge de travail :

  • Latence inférieure à 5 ms: Éliminez Pinecone. Une architecture client-serveur sur des terminaux périphériques ou dans des environnements hors réseau aura du mal à respecter ce temps de réponse. Localisez le processus d’intégration et privilégiez les bases de données fonctionnant sur le terminal et sur site. Vérifiez qu’elles respectent les contraintes de mémoire de votre matériel.
  • Conformité aux exigences relatives à l'« air gap »: Éliminez les bases de données cloud gérées. Elles nécessitent un accès au réseau et une validation de licence à distance. Utilisez des bases de données auto-hébergées telles que VectorAI DB et Qdrant. Le binaire de Qdrant, écrit en Rust, est léger, et son image Docker s’exporte au format fichier .tar . VectorAI DB est conçu pour les charges de travail vectorielles dans le cadre déploiement en air-gap.
  • Règles strictes en matière de localisation des données: Auditez l’ensemble du cycle de vie de vos données. Vérifiez où sont stockées les données clients, les données de télémétrie et les journaux système, par où elles transitent et où se trouvent les sauvegardes. Assurez-vous que le fournisseur de bases de données cloud exploitedes centres de données physiquement isolésà l’intérieur de vos limites de résidence. Privilégiez les bases de données locales telles que Weaviate et VectorAI DB,qui fonctionnent via Docker,afin de conserver un contrôle total sur vos données. Ces deux bases de données support la multi-location pour garantir la conformité en matière de résidence des données.

Audit n° 3 : charge de travail

C'est votre modèle de recherche qui détermine quelle architecture d'index est la plus adaptée.

  • Récupération en une seule étape: Utilisez des magasins de vecteurs prenant en charge HNSW pour le RAG, la recherche sémantique et les systèmes de recommandation. Ils sont optimisés pour une précision de rappel « top-K » et une faible latence de lecture. 
  • Mémoire d'agent à forte intensité d'écriture avec moins de 10 millions de vecteurs: Utilisez Postgres avec pgvector. L’index IVFFlat de pgvector permet de créer et de mettre à jour les index plus rapidement avec processeur minimale, et Postgres enregistre les nouveaux vecteurs d’embedding dans un journal d’écriture anticipée (WAL) afin que les agents ne perdent pas le fil du contexte de conversation en cours. Intégrez Mem0 pour gérer la compression sémantique et les transferts de mémoire entre le contexte à court terme de l’agent et Postgres. 
  • Mémoire d'agent à forte intensité d'écriture pour plus de 10 millions de vecteurs: Les charges de travail agentiques à grande échelle nécessitent un débit d'écriture élevé sans interruption due à la reconstruction des index. Utilisez streaming de Milvus pour écrire des vecteurs en continu, tandis que sa compaction en arrière-plan fusionne automatiquement les segments de données afin de maintenir requête . 

L'organigramme ci-dessous regroupe ces trois audits en un parcours décisionnel que vous pouvez suivre en fonction de votre propre pile. 

Comment choisir une base de données vectorielle ?

Organigramme d'aide à la décision pour le choix des bases de données vectorielles en 2026

Avant toute migration, procédez comme suit :

  1. Lancez VDBBench 1.0 sur votre propre charge de travail votre propre matériel.
  2. Documentez votre pipeline d'intégration si votre charge de travail sur Pinecone.
  3. Effectuez la mise à jour vers les versions 2.5.27+ ou 2.6.10+ avant toute modification architecturale sur Milvus.

Pour conclure

Le secteur des bases de données vectorielles n'est pas en déclin. Le segment des bases de données de moins de 50 millions de vecteurs se concentre autour de Postgres. Au-delà de ce seuil, les moteurs spécialisés continuent d'offrir des performances et une flexibilité opérationnelle que les bases de données polyvalentes ne peuvent égaler.

Les agents imposent une refonte de l'architecture de récupération, un défi qu'aucun fournisseur n'a encore pleinement relevé. Les charges de travail qui ne peuvent pas envoyer de données vers un serveur cloud restent le problème le moins bien pris en compte dans ce domaine.

La décision que vous prendrez ce trimestre n'a pas besoin d'attendre que le marché se stabilise. Votre nombre de vecteurs, déploiement et votre modèle de récupération indiquent déjà la réponse. Réalisez les trois audits et agissez en fonction de leurs résultats.

Si vos audits révèlent déploiement en périphérie, sur site ou en mode « air-gapped », il s'agit là du segment que la plupart des fournisseurs de solutions cloud natives ne peuvent pas prendre en charge avec leur architecture actuelle. VectorAI DB est conçu pour répondre à ces contraintes. Découvrez ce que les développeurs ont déjà réalisé grâce à cette solution dans les secteurs de la santé et de l'industrie.