Amazon ElastiCache Serverless for Valkey ajoute la recherche vectorielle, en texte intégral et hybride ainsi que les agrégations : Valkey 9 requis ; AWS annonce une latence « aussi basse que quelques microsecondes », un rappel vectoriel « jusqu'à 99 % » et « des milliards de requêtes par jour », des affirmations du fournisseur non testées ici, sans taille de données, matériel ni tarif indiqués

Le 10 novembre 2026, AWS a annoncé qu'Amazon ElastiCache Serverless for Valkey prend désormais en charge la recherche vectorielle, la recherche en texte intégral et la recherche hybride, ainsi que les agrégations. L'annonce décrit le problème visé : les applications qui cherchent dans des données en direct se heurtent à un compromis difficile entre latence et rappel, et les mises à jour mettent souvent du temps à devenir recherchables. Ce compte rendu s'appuie sur l'annonce d'AWS et sur la page « Getting started with Search » du guide de l'utilisateur d'ElastiCache. Tous les chiffres de vitesse et de rappel des deux pages sont des déclarations d'AWS. Aucune page ne nomme de jeu de données, de taille de vecteur, de matériel ni de méthode d'essai : ce compte rendu les traite donc comme des affirmations d'AWS assorties de réserves, qu'il n'a pas testées, et non comme des résultats mesurés.

L'annonce fait trois déclarations de performance. La recherche peut s'exécuter « avec une latence aussi basse que quelques microsecondes pour un rappel allant jusqu'à 99 % en recherche vectorielle » ; elle peut servir « des milliards de requêtes par jour » ; et les mises à jour sont recherchables « en quelques microsecondes seulement, dès que les écritures sont terminées ». La première et la troisième portent une réserve ; la deuxième non. « Aussi basse que » décrit un meilleur cas, pas un chiffre typique ni garanti. « Jusqu'à 99 % de rappel » est un plafond, et le rappel est la part des vrais plus proches voisins que la recherche trouve, ce qui varie avec les réglages d'index et les données. « Des milliards de requêtes par jour » est une affirmation de capacité sans conditions d'essai indiquées ; ce n'est ni une limite déclarée ni un quota journalier. Le guide ajoute qu'ElastiCache for Valkey offre « la recherche vectorielle à la plus faible latence, avec le plus haut débit et le meilleur rapport prix-performance à 95 % et plus de rappel parmi les bases de données vectorielles courantes sur AWS », sans données de comparaison sur la page. L'annonce dit qu'on peut régler le rappel selon ses besoins, ce qui implique que le compromis entre vitesse et rappel demeure et devient un réglage à choisir.

Côté fonctions, le guide liste la recherche en texte intégral en temps réel, la recherche exacte sur des étiquettes, la recherche par plage numérique, la recherche vectorielle et la recherche hybride. L'annonce dit qu'on peut combiner plusieurs types de recherche dans une seule requête et analyser les résultats avec des agrégations côté serveur. Les deux pages ne disent pas quelles combinaisons, quels opérateurs ou quelles commandes sont pris en charge, ni s'ils varient selon la version du moteur. Le guide renvoie pour cela aux pages distinctes « Search features and limits » et « Command Reference », que ce compte rendu n'a pas lues. L'annonce cite des usages comme la découverte de produits, les systèmes de recommandation et la génération augmentée par récupération. Le guide dit que la prise en charge vectorielle vise les plongements de fournisseurs tels qu'Amazon Bedrock, Amazon SageMaker, Anthropic ou OpenAI, et l'indexation, la recherche et la mise à jour de milliards de vecteurs de grande dimension avec jusqu'à 99 % de rappel. « Milliards » est une affirmation de conception ; les pages n'indiquent ni taille testée, ni coût, ni besoin en mémoire.

L'annonce présente aussi la fonction pour les agents d'IA. Elle dit que les développeurs peuvent donner à chaque agent, session ou tâche son propre magasin de données pour la mémoire et la récupération de contexte, de sorte que les agents puissent expérimenter, échouer et réessayer sans toucher à la production ni les uns aux autres. Chaque magasin, dit-elle, est prêt en quelques secondes, accessible par un point de terminaison public sans configuration réseau, et facturé seulement à l'usage, sans infrastructure à gérer. Un point de terminaison public est pratique. L'annonce ne décrit pas comment l'accès y est contrôlé, et une équipe de sécurité devrait lire la documentation d'ElastiCache sur l'authentification et le chiffrement avant de l'utiliser pour une mémoire d'agent pouvant contenir du texte sensible. Ce compte rendu n'a pas lu cette partie.

Les conditions de version sont les faits clés. L'annonce dit que la recherche est disponible sur ElastiCache Serverless for Valkey en version 9, dans toutes les régions commerciales d'AWS, les régions AWS GovCloud (USA) et la région AWS European Sovereign Cloud. On crée un nouveau cache serverless ou l'on met à niveau un cache existant vers Valkey 9 avec la console de gestion AWS, le kit SDK ou la CLI. Le guide donne un tableau plus large : la recherche fonctionne sur les clusters à base de nœuds avec Valkey 8.2 ou plus récent, et sur les caches ElastiCache Serverless avec Valkey 9.0 ou plus récent. Ce sont des versions minimales pour la recherche ; les pages ne montrent pas que chaque fonction de recherche est identique sur chaque version. Un cache existant sur une version plus ancienne du moteur doit donc d'abord être mis à niveau, et les pages ne décrivent pas ce que cela implique. L'annonce décrit Valkey comme « l'alternative open source la plus permissive et neutre vis-à-vis des fournisseurs à Redis, et le moteur recommandé pour ElastiCache ». C'est la description par AWS de sa propre recommandation.

Le guide liste trois sous-sujets sous la recherche : fonctions et limites, choix de la configuration appropriée, et limitation des écritures de recherche. Le dernier compte. Un cache qui met à jour des données recherchables dès que les écritures sont terminées doit se protéger sous forte charge d'écriture, et l'existence d'un sujet sur la limitation laisse penser que des limites s'appliquent. La page capturée ici ne les explique pas : l'affirmation que les mises à jour sont recherchables « dès que les écritures sont terminées » doit donc être testée à votre propre débit d'écriture. Le guide dit aussi que, pour les flux de travail d'agents, il existe une « ElastiCache Skill » et un serveur MCP Valkey qui gèrent les index, génèrent des plongements vectoriels et offrent un outil de recherche unifié. Ce compte rendu ne les a pas testés.

Plusieurs choses manquent dans les sources. Il n'y a pas de prix : l'annonce renvoie à la page de tarification. Il n'y a pas de benchmark avec taille de données, dimension de vecteur ou matériel indiqués, pas de comparaison avec d'autres bases vectorielles au-delà de l'affirmation d'AWS, et pas de description de l'usage mémoire par million de vecteurs. Une équipe qui compare cela à un magasin de recherche ou de vecteurs distinct devrait faire son propre test avec ses vrais vecteurs, filtres et débit d'écriture, mesurer le rappel à la latence dont elle a besoin et comparer le coût à la page de tarification. Le gain pratique, si les affirmations tiennent, est de garder dans un seul service des données clé-valeur rapides et la recherche. Les pages ne prouvent pas qu'elles tiennent.