Amazon S3 Vectors va-t-il tuer les bases de données vectorielles — ou les sauver ?
Il n’y a pas si longtemps, AWS a lancé quelque chose de nouveau : S3 Vectors. C’est leur première tentative de solution de stockage vectoriel, vous permettant de stocker et d’interroger des embeddings vectoriels pour la recherche sémantique directement dans Amazon S3.
À première vue, cela ressemble à une base de données vectorielle légère fonctionnant au-dessus d’un stockage d’objets à faible coût — à un niveau de prix clairement attractif par rapport à de nombreuses solutions dédiées de bases de données vectorielles.
amazon s3 vectors.png
Naturellement, cela a suscité de nombreuses réactions tranchées. J’ai vu des personnes sur les réseaux sociaux et dans des cercles d’ingénierie dire que cela pourrait être la fin des bases de données vectorielles spécialisées — Milvus, Pinecone, Qdrant et d’autres inclus. Affirmation audacieuse, non ?
En tant qu’architecte ingénierie de Milvus et quelqu’un qui a passé beaucoup trop de nuits à réfléchir à la recherche vectorielle, je dois admettre que : S3 Vectors apporte quelque chose d’intéressant, en particulier autour du coût et de l’intégration au sein de l’écosystème AWS. Mais au lieu de “tuer” les bases de données vectorielles, je le vois s’intégrer dans l’écosystème comme un élément complémentaire. En fait, son véritable avenir réside probablement dans le fait de travailler avec des bases de données vectorielles professionnelles, et non de les remplacer.
Dans cet article, je vais vous expliquer pourquoi je pense cela — en l’examinant sous trois angles : la technologie elle-même, ce qu’elle peut et ne peut pas faire, et ce que cela signifie pour le marché.
Un fait surprenant : le stockage vectoriel peut coûter plus cher que les appels LLM
La recherche vectorielle est puissante, mais elle s’accompagne d’un sérieux inconvénient : elle est coûteuse. Les exigences de calcul sont souvent un à deux ordres de grandeur supérieures à ce que l’on observe dans une base de données NoSQL typique. Cet écart n’est pas seulement théorique — il apparaît dans les factures réelles.
J’ai récemment parlé avec le CTO d’une application populaire de prise de notes IA qui m’a confié quelque chose de surprenant : ils dépensent deux fois plus pour la recherche vectorielle que pour les appels API OpenAI. Pensez-y une seconde. Faire fonctionner la couche de récupération leur coûte plus cher que de payer le LLM lui-même. Cela renverse complètement l’hypothèse habituelle.
Le boom de ChatGPT en 2022 n’a fait que rendre cela plus évident. Soudain, les embeddings étaient partout, et les données vectorielles sont devenues le type de données connaissant la croissance la plus rapide sur le cloud public. Retrieval-Augmented Generation (RAG) en était le moteur — et avec lui sont apparus trois défis qui ont remodelé ce qu’une base de données vectorielle comme Milvus devait faire :
Explosion massive des données : Les charges de travail sont passées de dizaines de millions à des dizaines de milliards de vecteurs presque du jour au lendemain. Ce n’est pas une croissance linéaire — c’est un saut quantique, et cela a brisé les anciennes façons de gérer les données.
La tolérance à la latence a changé : Comme les LLM mettent de toute façon du temps à générer des réponses, les utilisateurs sont devenus plus tolérants envers une récupération légèrement plus lente. L’état d’esprit “rappel sous les 10 ms à tout prix” a soudainement perdu de son importance.
La sensibilité aux coûts a explosé : Doubler ou tripler le volume de données n’était pas seulement un problème de stockage ; c’est devenu une crise financière si l’on essayait de passer à l’échelle avec des conceptions traditionnelles très gourmandes en calcul.
En bref : les bases de données vectorielles ont dû évoluer rapidement, non pas parce que la technologie ne fonctionnait pas, mais parce que l’économie de la récupération s’est soudainement retrouvée au premier plan.
L’évolution du stockage vectoriel : de la mémoire au disque, et maintenant au stockage d’objets
La pression autour des coûts et de l’échelle a imposé une conclusion : les bases de données vectorielles ne pouvaient pas rester uniquement en mémoire indéfiniment. Elles devaient évoluer — d’abord vers le disque, puis maintenant vers le stockage d’objets comme S3. Ce n’était pas un choix ; c’était une inévitabilité industrielle. Et si vous suivez ce domaine, vous avez probablement remarqué la même tendance que moi au cours des dernières années.
J’ai vu les bases de données vectorielles passer par trois étapes distinctes :
Phase I (2018–2022) : l’ère de la mémoire pure : Aux débuts de Milvus, nous nous appuyions sur des index en mémoire comme HNSW et IVF. Les performances et le rappel étaient fantastiques — mais les coûts étaient brutaux. La mémoire ne passe pas à l’échelle à bas coût, et tous ceux qui payaient ces factures cloud le savaient.
Phase II (2022–2024) : la révolution de l’index sur disque : Pour briser le goulot d’étranglement de la mémoire, nous avons été pionniers d’une approche basée sur disque utilisant DiskANN ainsi que notre index propriétaire Cardinal (exclusif à Zilliz Cloud, le Milvus managé). Avec des astuces comme les E/S asynchrones (AIO) et io_uring, nous avons réussi à tirer de vraies performances des disques. Le résultat ? Une réduction des coûts de 3 à 5x. Nos unités de calcul (CUs) optimisées pour la capacité sont rapidement devenues des best-sellers dans Zilliz Cloud.
Phase III (2024– ) : l’ère du stockage par niveaux : L’étape suivante était évidente : pousser les index vectoriels vers le stockage objet bon marché. De nouveaux acteurs comme TurboPuffer ont misé entièrement sur S3, faisant tomber les coûts de stockage à environ 0,33 $/Go/mois — une réduction de 10x. Mais le compromis était tout aussi clair : une latence des requêtes à froid dans la plage de 500 ms à 1 s, et une précision de rappel plus faible.
Chez Zilliz, nous travaillons depuis un certain temps sur le stockage par niveaux, mais nous avons retardé la sortie jusqu’à pouvoir maîtriser les performances des requêtes à froid. Le mois prochain, nous déploierons nos CUs à capacité étendue améliorées avec une véritable séparation chaud/froid dans Zilliz Cloud. Cela signifie une latence stable des requêtes à froid inférieure à 500 ms, associée à un QPS ultra-élevé pour les requêtes à chaud. Autrement dit, le meilleur des deux mondes.
Amazon S3 Vectors arrive à point nommé
Alors que le stockage par niveaux a déjà fait ses preuves, il n’est pas surprenant qu’AWS soit entré dans la danse avec S3 Vectors. En fait, cette sortie ressemble à une extension naturelle de ce qui se produisait déjà dans l’industrie. Amazon élargissait le rôle de S3 avec des fonctionnalités comme S3 Tables, le faisant évoluer de « simple stockage objet » vers une colonne vertébrale de stockage à froid multimodale. Les vecteurs sont simplement la modalité suivante dans cette évolution — et cela ne s’arrêtera probablement pas là. Les graphes, les données clé-valeur et les séries temporelles pourraient tous suivre le même chemin.
Et Amazon apporte trois avantages indéniables :
Coût inférieur : parmi les tarifs de stockage les plus bas du secteur.
Échelle massive : les pools de machines d’AWS peuvent absorber presque n’importe quelle charge de requêtes.
Architecture native microservices : parfaitement alignée avec le workflow écriture–construction–requête de l’indexation vectorielle.
Ensemble, ces éléments donnent à S3 Vectors les bases d’une solution de stockage à froid pour vecteurs à très faible coût et hautement scalable.
S3 Vectors est un véritable tueur de prix, mais avec des limites claires
Dès l’annonce de S3 Vectors, notre équipe l’a soumis à des tests complets. Les résultats ont été révélateurs — non seulement en termes de coût, mais aussi quant aux endroits où les fissures commencent à apparaître.
S3 Vectors est un véritable tueur de prix
Impossible de le nier : S3 Vectors est incroyablement rentable.
Le stockage ne coûte que $0.06/Go, soit environ 5 fois moins cher que la plupart des solutions vectorielles serverless. Pour une charge de travail représentative — disons 400 millions de vecteurs plus 10 millions de requêtes par mois — la facture s’élève à environ $1,217/mois. C’est une réduction de plus de 10x par rapport aux bases de données vectorielles traditionnelles. Pour les charges à faible QPS et tolérantes à la latence, c’est presque imbattable.
Mais les performances ont de véritables contraintes
Limites de taille des collections : Chaque table S3 plafonne à 50 M de vecteurs, et vous ne pouvez créer que jusqu’à 10 000 tables.
Requêtes à froid : La latence se situe à ~500 ms pour 1 M de vecteurs et à ~700 ms pour 10 M de vecteurs.
Requêtes à chaud : La latence reste sous les 200 ms à 200 QPS, mais dépasser ce plafond de 200 QPS est difficile.
Performances d’écriture : Plafonnées à moins de 2 Mo/s. C’est plusieurs ordres de grandeur inférieur à Milvus (qui gère des Go/s), même si, à son crédit, les écritures ne dégradent pas les performances des requêtes. Traduction : ce n’est pas conçu pour les scénarios avec de grands jeux de données fréquemment modifiés.
Compromis entre précision et fonctionnalités
C’est sur la précision que les choses se compliquent. Le rappel oscille autour de 85–90 %, et vous ne disposez d’aucun réglage pour l’augmenter. Ajoutez des filtres, et le rappel peut tomber sous les 50 %. Dans un test où nous avons supprimé 50 % des données, les requêtes TopK demandaient 20 résultats mais ne pouvaient en renvoyer que 15.
Les fonctionnalités sont également réduites. Les requêtes TopK plafonnent à 30. Les métadonnées par enregistrement sont soumises à des limites de taille strictes. Et vous ne trouverez pas de fonctionnalités comme la recherche hybride, le multi-tenant ou le filtrage avancé — qui sont toutes indispensables pour de nombreuses applications en production.
Analyse de S3 Vectors : l’architecture probable
Après avoir exécuté des tests et les avoir rapprochés de modèles de conception AWS familiers, nous avons formulé une hypothèse assez solide sur le fonctionnement interne de S3 Vectors. Bien qu’Amazon n’ait pas publié tous les détails, les caractéristiques de performance pointent vers cinq technologies clés :
Indexation dynamique SPFresh : Au lieu de reconstruire des index entiers après chaque écriture, S3 Vectors semble ne mettre à jour que les portions affectées. Cette conception maintient les coûts d’écriture bas et une disponibilité élevée, mais elle a un prix : les taux de rappel baissent de quelques points de pourcentage après les mises à jour.
Quantification profonde (PQ 4 bits) : Pour réduire la surcharge d’E/S de S3, les embeddings sont probablement compressés à l’aide d’une quantification produit 4 bits.
L’avantage : le stockage est peu coûteux, et les requêtes restent rapides.
L’inconvénient : le rappel plafonne autour de ~85 %, et les développeurs ne disposent d’aucun réglage pour l’augmenter.
Mécanisme de post-filtrage : Le filtrage semble être appliqué après la récupération grossière. Cela permet de garder l’index unifié et simple, mais il peine avec les conditions complexes. Lors de nos tests, lorsque nous avons supprimé 50 % des données, les requêtes TopK demandant 20 résultats n’en ont renvoyé que 15 — des signes classiques d’un pipeline de post-filtrage. Cela suggère également qu’Amazon s’est largement appuyé sur des conceptions d’index open-source existantes plutôt que de construire une solution personnalisée à partir de zéro.
Mise en cache multi-niveaux : Les requêtes à chaud se comportent beaucoup plus rapidement, probablement grâce à un cache SSD/NVMe placé devant S3. Mais lorsqu’une requête manque le cache, la latence augmente fortement. Ce schéma correspond à une hiérarchie de cache multi-niveaux conçue pour masquer la lenteur inhérente au stockage objet.
Ordonnancement distribué à grande échelle : AWS ne manque pas de pools de machines. S3 Vectors semble répartir la charge de travail entre des microservices, en mettant en pipeline le flux lecture → décompression → recherche. Le résultat est ce que nous avons observé dans les tests : une distribution de latence remarquablement stable, même sous forte charge.
Où S3 Vectors trouve sa place : le bon outil pour des tâches spécifiques
Après avoir mis S3 Vectors à l’épreuve, il est clair qu’il excelle dans certains scénarios et montre ses limites dans d’autres. Comme la plupart des outils d’infrastructure, ce n’est pas une solution universelle — c’est le bon outil pour le bon usage.
Là où il fonctionne bien
Archivage de données froides : Parfait pour stocker des jeux de données historiques rarement consultés. Si vous pouvez accepter des temps de requête de 500 ms et plus, les économies de coût sont imbattables.
Requêtes RAG à faible QPS : Pensez à de petits outils internes ou à des chatbots qui n’exécutent que quelques dizaines de requêtes par jour, en restant sous les 100 QPS. Pour ces cas d’usage, la latence n’est pas un obstacle majeur.
Prototypage à faible coût : Idéal pour les projets de preuve de concept où l’objectif est de tester une idée sans dépenser lourdement en infrastructure.
Là où il peine
Recherche et recommandation hautes performances : Si votre application nécessite une latence inférieure à 50 ms, S3 Vectors n’est tout simplement pas conçu pour cela.
Écritures à haut volume ou mises à jour fréquentes : Les performances se dégradent rapidement, et la précision du rappel baisse nettement en cas de forte volatilité.
Charges de requêtes complexes : Il n’y a pas de prise en charge de la recherche hybride, des agrégations ou d’autres fonctionnalités de requêtage avancées.
Applications de production multi-locataires : Avec une limite stricte de 10 000 buckets, ce n’est pas conçu pour les déploiements multi-locataires à grande échelle.
En d’autres termes, S3 Vectors est excellent pour les scénarios froids, peu coûteux et à faible QPS, mais ce n’est pas le moteur que vous voulez utiliser pour alimenter un système de recommandation, une application de recherche en temps réel ou tout système de production à grande échelle.
L’avenir est au stockage vectoriel par niveaux
S3 Vectors ne signe pas la fin des bases de données vectorielles : il confirme quelque chose que beaucoup d’entre nous constatent depuis un moment : l’avenir est au stockage par niveaux. Au lieu de conserver chaque vecteur dans une mémoire coûteuse ou sur un disque rapide, les charges de travail se répartiront naturellement entre des niveaux chauds, tièdes et froids, en fonction de la fréquence d’accès et du type de latence que l’application peut tolérer.
Voici à quoi cela ressemble en pratique :
Couche de données chaudes (<50 ms) – C’est là que se trouvent la recherche en temps réel, les recommandations et les publicités ciblées. La latence doit être inférieure à 50 ms, ce qui signifie que les bases de données vectorielles spécialisées restent la meilleure option. Elles sont optimisées à la fois pour une vitesse fulgurante et un débit de requêtes élevé.
Couche de données tièdes (50–500 ms) – De nombreuses applications basées sur RAG et services partagés multi-locataires entrent dans cette catégorie. Ces charges de travail n’ont pas besoin d’une latence ultra-faible, mais elles nécessitent des performances prévisibles à moindre coût. S3 Vectors et les instances de stockage par niveaux de Milvus correspondent à ce juste milieu.
Couche de données froides (>500 ms) – Les archives historiques et l’analyse hors ligne ne nécessitent pas de réponses en temps réel, une latence de l’ordre de centaines de millisecondes est donc acceptable. Ce qui compte ici, c’est l’efficacité des coûts à très grande échelle. C’est là que des solutions comme S3 + Spark/Daft ou le lac de données vectorielles Milvus excellent.
La séparation chaud–tiède–froid équilibre latence, coût et échelle d’une manière qu’aucun niveau de stockage unique ne peut couvrir à lui seul. C’est un schéma que nous avons déjà observé dans les bases de données relationnelles, les entrepôts de données et même les CDN — et le stockage vectoriel suit désormais la même trajectoire. Cette architecture à trois niveaux s’aligne également étroitement sur la feuille de route que nous avons construite pour Milvus et Zilliz Cloud.
1. Une architecture unifiée de traitement en ligne + hors ligne
Les applications d’IA ne vivent pas sagement dans des mondes « en ligne » et « hors ligne » séparés. En réalité, les données circulent constamment entre les deux. C’est pourquoi, avec le prochain Milvus 3.0, nous introduirons un lac de données vectorielles, conçu pour prendre en charge à la fois la récupération en temps réel et le traitement hors ligne à partir du même jeu de données.
En pratique, cela signifie qu’un seul jeu de données peut alimenter vos requêtes RAG et de recherche en direct, tout en alimentant aussi une analyse hors ligne basée sur Spark — par exemple, la curation de données d’entraînement pour les LLMs. Pas de duplication, pas de gestion de deux pipelines différents.
Nous déploierons également le format StorageV2 pour le lac de données vectorielles, qui porte l’économie à un autre niveau :
Jusqu’à 100x moins cher pour le stockage de données froides.
Jusqu’à 100x plus rapide que les requêtes Spark en force brute sur des données chaudes.
Le résultat est un système unifié qui minimise la redondance, garde les coûts sous contrôle et rend le travail avec les données vectorielles beaucoup moins pénible.
2. Créer les fonctionnalités dont les développeurs IA ont réellement besoin
Au cours des deux dernières années, les applications d’IA ont évolué rapidement — et les exigences pour l’infrastructure qui les sous-tend aussi. Chez Zilliz, nous avons fait progresser Milvus au rythme de ces besoins, en livrant des fonctionnalités comme la recherche hybride BM25 + vectorielle, l’isolation multi-tenant, le stockage hiérarchisé hot–cold, et la déduplication MinHash, ainsi qu’une longue liste d’améliorations axées sur les développeurs.
Notre philosophie est simple : lorsque vous combinez une compréhension approfondie des cas d’usage métier avec les technologies les plus récentes, vous ouvrez la voie à des possibilités d’infrastructure entièrement nouvelles. C’est cet état d’esprit qui façonne Milvus 3.0, qui apportera une nouvelle vague de fonctionnalités AI-native conçues directement pour les applications du monde réel. Parmi elles :
Pondération des mots-clés dans la recherche – Pour qu’une requête comme « téléphone rouge » puisse donner la priorité à rouge de manière appropriée.
Prise en charge de la géolocalisation – Stocker et interroger des vecteurs sensibles à la localisation pour traiter des prompts comme « trouver des cafés à proximité ».
Prise en charge multi-vecteur pour le RAG – Associer plusieurs embeddings à chaque texte, améliorant le rappel et la précision dans les tâches de récupération complexes.
Traitement UDF flexible – Des fonctions définies par l’utilisateur pour un traitement des données plus riche et personnalisable.
Outils d’analyse visuelle – Une exploration de données et une fouille hors ligne plus approfondies à grande échelle.
Et ce n’est que le début. Le point le plus important, c’est que Milvus évolue vers un système qui est non seulement efficace et scalable, mais AI-native dans son essence — conçu spécifiquement pour la manière dont les applications modernes fonctionnent réellement.
3. Concevoir pour le passage à l’échelle sans le prix qui va avec
Chez Zilliz, nous croyons que : une réduction des coûts par 10 ouvre la porte à 100 fois plus de cas d’usage applicatifs. Ce principe a guidé chaque grande étape de Milvus. Depuis 2022, nous avons introduit des index basés sur disque, l’accélération GPU et la quantification RabitQ — autant d’éléments qui ont fait progresser les performances des requêtes de plusieurs ordres de grandeur tout en faisant baisser les coûts.
Pour la suite, notre priorité est d’extraire encore plus d’efficacité de la stack :
Optimisation matérielle plus poussée – Ajustement pour la puissance de calcul brute et les performances IOPS.
Compression et quantification plus intelligentes – Rendre les vecteurs plus légers sans sacrifier la précision.
Arrêt anticipé pour les requêtes d’index – Interrompre les calculs inutiles dès que nous avons des résultats fiables.
Indexation hiérarchisée affinée – Une meilleure utilisation du cache pour un accès plus rapide aux données froides.
L’objectif final n’a pas changé : construire une infrastructure qui fonctionne immédiatement, évolue à la demande, et reste à la fois rapide et abordable.
Pourquoi l’arrivée de S3 Vectors est une bonne nouvelle pour tout le monde
Beaucoup de gens craignent que S3 Vectors rende les bases de données vectorielles traditionnelles obsolètes. Mon point de vue est à l’opposé : sa sortie est une bonne nouvelle pour toute l’industrie. En fait, j’y vois trois grands avantages.
Cela valide la demande. Plus personne ne peut prétendre que les vecteurs ne sont qu’un effet de mode. Si AWS construit un produit autour de cela, c’est la preuve évidente que le stockage vectoriel est une véritable nécessité — et pas simplement des « index enveloppés dans une base de données ».
Cela éduque le marché. Grâce à la portée d’AWS, davantage d’entreprises connaissent désormais les bases de données vectorielles, ce qui élargit les possibilités en matière d’applications pouvant être créées.
Cela stimule l’innovation. La concurrence nous pousse tous — Milvus compris — à optimiser davantage, à réduire encore les coûts et à trouver des forces différenciatrices.
Du point de vue du positionnement, S3 Vectors ressemble moins à une base de données vectorielle complète qu’au niveau froid du stockage vectoriel. Son faible coût le rend particulièrement attrayant pour des scénarios qui étaient auparavant hors budget : petites équipes construisant des applications RAG, développeurs individuels faisant des expérimentations, ou organisations indexant d’immenses jeux de données avec seulement des besoins de recherche basiques. C’est un véritable déblocage pour l’écosystème.
Personnellement, je tiens également à saluer l’équipe d’ingénierie d’AWS. Elle améliore régulièrement sa plateforme — du débogage de Lambda aux performances de démarrage à froid — et S3 Vectors est un autre exemple d’innovation produit réfléchie. Je suis sincèrement curieux de voir ce que les développeurs vont construire maintenant que les conditions économiques sont aussi favorables.
Donc non, le marché des bases de données vectorielles n’est pas en train d’être bouleversé — il mûrit pour devenir un écosystème à plusieurs niveaux, où différentes solutions répondent à différents besoins de performance et de coût. C’est une bonne chose pour les entreprises, pour les développeurs et pour l’ensemble de la pile d’infrastructure IA.
L’âge d’or des bases de données vectorielles n’est pas terminé — il ne fait que commencer.
Continuer à lire
A Few Notes from Databricks Data + AI Summit 2026: Why the Data Layer Matters Again
James Luan shares notes from Databricks Data + AI Summit 2026 on why production AI is pushing the data layer back to the center of infrastructure.
Why and How to Migrate from Self-Hosted Milvus to Zilliz Cloud
A simple, step-by-step guide to migrating from Milvus to Zilliz Cloud. Learn both endpoint and backup methods for a smooth, scalable vector database migration.
Why Deepseek is Waking up AI Giants Like OpenAI And Why You Should Care
Discover how DeepSeek R1's open-source AI model with superior reasoning capabilities and lower costs is disrupting the AI landscape and challenging tech giants like OpenAI.