vege - stock.adobe.com
Bases de données vectorielles : Qdrant et Pinecone tentent de se différencier
À l’heure de l’unification des modèles et des types de données, Qdrant et Pinecone multiplient les fonctions pour prouver l’avantage des bases de données spécialisées dans la recherche vectorielle.
Les géants du cloud, Oracle et les éditeurs de bases de données les plus populaires, dont MongoDB et Elastic, ont repris la main sur les sujets de la recherche vectorielle. Dès lors, les acteurs spécialisés doivent trouver des arguments pour continuer d’attirer les clients. C’est le cas des deux startups les plus populaires de cette catégorie : Qdrant et Pinecone.
En la matière, les deux acteurs affichent une stratégie technique similaire : miser sur la robustesse, la performance et les gros cas d’usage.
Le 19 novembre, Qdrant a annoncé la disponibilité de sa version 1.16 de sa base de données éponyme. L’une des fonctionnalités principales mises en avant par l’éditeur n’est autre qu’une révision de son mécanisme multitenant.
Dans son cas, il s’agit à la fois de partager une instance du SGBD entre plusieurs utilisateurs, mais également de partitionner les vecteurs. L’éditeur veut s’assurer que chaque usager d’une application RAG n’ait accès qu’à ces propres vecteurs, et non ceux des voisins.
Jusqu’alors, Qdrant proposait deux approches : un découpage des tenants par charge utile et un autre basé sur le sharding. Le premier mode est plus adapté à la gestion concurrente d’un grand nombre de petits tenants. Le second fonctionne bien quand il faut dédier des ressources « à un petit nombre de grands tenants ». Un bon moyen d’éviter le problème des voisins bruyants, indique Qdrant.
Multitenant avancé, stockage sur disque, recherche plus précise : Qdrant aligne ses atouts
Or l’éditeur s’est rendu compte que dans le monde réel, les schémas de déploiement sont à cheval entre les deux approches. Certaines collections de documents sont plus volumineuses que d’autres.
D’où la mise en place d’un mode multitenant à plusieurs étages. Il est ainsi possible de faire cohabiter deux niveaux d’isolation de tenants dans une seule collection de vecteurs. Pour ce faire, Qdrant s’appuie sur son mécanisme de sharding. Les petits tenants sont rassemblés dans des shards partagés, tandis que les gros tenants ont le droit à des shards dédiés. Cette isolation des grands tenants est fonction d’un système de nommage.
Une fonction de routage permet d’acheminer les requêtes vers les petits ou les grands shards, sans nécessiter de le préciser. Par ailleurs, les shards partagés peuvent être dédiés quand ils sont suffisamment grands à travers un système de transfert activable à l’aide d’une commande. Une fois cette promotion terminée, les requêtes sont automatiquement acheminées.
Les deux autres fonctionnalités concernent l’indexation vectorielle et la compression des vecteurs en mémoire vive.
Qdrant se distingue par son implémentation de l’algorithme orienté graphes HNSW (Hierarchical Navigable Small World). L’éditeur y a ajouté un système de filtres. Ce mécanisme permet d’ajouter des nœuds additionnels correspondant à des charges utiles indexées à ce graphe de vecteurs. L’idée est de réduire la quantité de ressources de calcul nécessaire à la recherche tout en maintenant sa qualité.
Or cette approche a des limites avec des filtres à haute cardinalité ou lorsque les critères de filtrage ne sont pas connus en avance. Dans ce cas-là, la précision de la recherche est grandement affectée.
En ce sens, Qdrant introduit la prise en charge de l’algorithme ACORN. Celui-ci « permet d’effectuer une première traversée entre les voisins directs du graphe, mais également une seconde traversée quand les voisins directs ont été filtrés », indique Qdrant. L’approche n’est cependant pas sans contrepartie : elle améliore la précision, mais affecte les performances. En clair, la recherche est plus lente. Toutefois, l’éditeur permet d’enclencher ACORN à la requête suivant leur complexité, en complément d’HNSW et l’indexation par charge utile.
Enfin, une troisième fonctionnalité phare de cette version 1.16 correspond à ce que Qdrant appelle le « stockage en ligne ». Ce mode permet de stocker des vecteurs quantisés (compressés) directement au sein des nœuds HNSW, sur disque SSD, et non en mémoire vive.
Par défaut, les index HNSW impliquent des accès aléatoires. Ils ont été conçus pour fonctionner en mémoire. Or, plus de vecteurs il y a, plus il faut de mémoire vive disponible pour exécuter les requêtes. Et, historiquement, à volume égal, la RAM coûte plus cher que le stockage flash.
Pour pallier la lenteur des accès aléatoires sur disque, Qdrant exploite la lecture paginée. Les données sont lues par blocs consécutifs. Les vecteurs originaux sont inclus dans le même graphe pour effectuer un reclassement implicite lors de la recherche. Logiquement, cela permet d’accélérer la recherche, mais nécessite de multiplier par trois ou quatre l’espace de stockage. Dans sa documentation, l’éditeur décline plusieurs scénarios suivant l’équilibre entre précision, quantité de mémoire, stockage sur disque et vitesse.
Avec DRN, Pinecone cible les champions de la recherche sémantique
Quid de Pinecone ? Le concurrent de Qdrant a lancé le 1er décembre la préversion publique de ses nœuds dédiés à la lecture (Dedicated Read Nodes, DRN) sur AWS, Google Cloud et Azure. Cette offre cloud facturée à l’heure sert à traiter un grand nombre de requêtes à la seconde sur des index contenant des milliards de vecteurs. Ce service est davantage adapté à « la recherche sémantique, aux moteurs de recommandations et services critiques », dixit l’éditeur.
De manière générale, DRN est contre-indiqué pour les systèmes RAG au nombre de requêtes inconsistant, les applications agentiques peu utilisées, les prototypes ou tout traitement en lot. Ici, Pinecone vise les gros cas d’usage en production, par exemple ceux des plateformes e-commerce.
Ces nœuds sont réservés pour les index, ce qui empêche, ici aussi, le problème des voisins bruyants. Les vecteurs ne sont pas stockés dans des objets, mais en mémoire et sur disques SSD locaux au sein des nœuds dédiés.
L’éditeur propose deux types de nœuds suivant les performances souhaitées. La capacité de stockage d’un index est déterminée par son nombre de shards. Chaque shard contient 250 Go de stockage. « Pour maintenir des performances optimales, provisionnez des shards supplémentaires pour maintenir votre index à 70-80 % de sa capacité », recommande l’éditeur. « Par exemple, un index de 500 Go nécessitera 3 shards (capacité de 750 Go = 67 %) plutôt que 2 unités (capacité de 500 Go = 100 %) », illustre Pinecone, dans sa documentation.
Aussi, les clients décident du nombre de répliques, en fonction du volume de requêtes attendu.
« En général, le débit augmente de façon linéaire avec les répliques. Par exemple, si une réplique gère 50 QPS à votre latence cible, deux répliques devraient gérer environ 100 QPS », peut-on lire dans la documentation.
Pinecone proposait déjà un service On Demand (et serverless). Selon l’éditeur, son offre DRN est « plus efficiente financièrement » pour les grands cas d’usage en production.
Gartner donne la primauté aux bases de données multimodèle
Selon le Magic Quadrant 2025 consacré aux systèmes de gestion de bases de données cloud paru le 18 novembre, l’indexation des vecteurs, utile pour la mise en place de systèmes de recherche augmentée par l’IA générative (Retrieval Augmented génération, RAG) est une fonctionnalité « commune ». Selon Gartner, elle n’est pas obligatoire pour faire partie du classement.
Son adoption s’est cependant généralisée à partir de l’année dernière, notent les analystes. Cependant, ce n’est qu’une des fonctionnalités prises en compte par le cabinet. Les fonctions de RAG as a Service, la conversion de documents en vecteurs, l’ajout de fonctions IA dans le système de requêtes, de copilotes ou de migration automatisés sont autant de critères que Gartner compte surveiller à l’avenir.
Et de saluer SAP, Oracle, Google, Microsoft, SingleStore et Neo4j pour leur capacité vectorielle.
Comme le suggère de fournisseur de solutions relationnelles dans cette liste, l’adoption de systèmes translytiques ou multimodèle (un terme à attribuer à Forrester), visant à rassembler les charges de travail opérationnelles et analytiques sur la même plateforme. Le recours croissant à PostgreSQL en est la preuve. Cependant, comme Pinecone et Qdrant, d’autres, dont AWS, croient toujours en l’avantage des bases de données spécialisées.
« AWS offre à ses clients un vaste choix de services SGBD et d’options d’intégration », reconnaît Gartner. « Cependant, les caractéristiques de ces produits, qui se chevauchent et entrent en conflit, peuvent être source de confusion, ce qui rend difficile pour les clients de déterminer les solutions dont ils ont besoin ». Un vieux conflit qui risque de perdurer.
