DynamoDB intègre la recherche vectorielle et supprime le vector store séparé
AWS a annoncé la disponibilité générale de la recherche vectorielle native dans DynamoDB, où les embeddings cohabitent avec les données opérationnelles et une API SearchVectors renvoie les plus proches voisins. Pour qui a déjà ses données dans DynamoDB, c’est la fin de la synchronisation vers un vector store dédié.
5 août 2026. AWS annonce la disponibilité générale de la recherche vectorielle dans Amazon DynamoDB. On peut désormais stocker ses embeddings à côté de ses données opérationnelles, dans la même table, et interroger les plus proches voisins avec une API SearchVectors — sans répliquer quoi que ce soit vers une base vectorielle séparée. C’est la disparition d’une architecture entière : celle du vector store synchronisé à la main.
Le schéma dominant depuis trois ans était bancal. Les données vivaient dans DynamoDB, les vecteurs dans OpenSearch, Pinecone ou pgvector, et un pipeline de synchronisation recopiait en permanence de l’un vers l’autre. Trois coûts s’empilaient : la maintenance du pipeline, le mouvement de données facturé, et la latence de bout en bout. La promesse de DynamoDB tient en une phrase : les vecteurs et les attributs partagent la même infrastructure serverless et le même modèle de paiement à la requête.
Ce que fait la version GA
Le mécanisme est simple à décrire. On génère les embeddings avec le modèle de son choix — Amazon Bedrock Titan Text Embeddings, Cohere Embed, ou un modèle OpenAI — puis on les stocke dans un attribut de type List de nombres, sans nouveau type ni changement de schéma. On crée ensuite un index vectoriel sur cet attribut en précisant trois choses : le nombre de dimensions, la fonction de distance, et les éventuels attributs de filtre.
L’interrogation passe par SearchVectors : on fournit un vecteur de requête, le nombre de résultats (Top K, plafonné à 100), et des conditions de filtre optionnelles. La réponse renvoie les éléments les plus proches, classés par score de similarité, avec leurs attributs opérationnels dans le même appel.
Les bornes techniques sont à connaître avant de choisir. Jusqu’à 4 096 dimensions, trois fonctions de distance — euclidienne, cosinus et produit scalaire — et une latence de l’ordre de la milliseconde avec plus de 99 % de rappel, annoncée comme valable « jusqu’à des milliers de milliards de vecteurs ». Le filtrage inline ne supporte que l’égalité stricte : pas de BETWEEN, pas de BEGINS_WITH.
La clé de voûte : la clé de partition
Un détail d’architecture distingue cette implémentation d’un vector store générique : l’index vectoriel peut porter une clé de partition. Chaque recherche est alors bornée à une seule valeur de clé de partition, ce qui évite de balayer tout l’index et préserve des latences prévisibles à grande échelle.
L’exemple de la documentation est parlant : un catalogue de produits qui sert plusieurs marchés indexe ses descriptions, avec marketplace comme clé de partition. Une recherche de « chaussures de running légères pour l’été » se fait alors dans un seul marché, filtrée par category = footwear, sans jamais toucher le reste de l’index. C’est la même logique de partitionnement que le reste de DynamoDB — et c’est ce qui permet au service de « passer à l’échelle horizontalement » sans dégrader la latence.
La conséquence pratique : la clé de partition est optionnelle mais recommandée dès que le volume de vecteurs ou le débit de requêtes devient important. Sans elle, chaque SearchVectors doit parcourir l’ensemble des vecteurs, ce qui fonctionne — mais coûte plus cher et répond moins vite à mesure que l’index grossit.
Le vrai arbitrage : un seul socle ou un spécialiste
La question n’est pas « est-ce que ça marche » — ça marche — mais « à partir de quand le spécialiste reste supérieur ». Trois cas penchent encore en faveur d’un vector store dédié.
D’abord, la recherche hybride. OpenSearch et les moteurs spécialisés combinent full-text et vectoriel dans une même requête, avec du reranking et des scores fusionnés. DynamoDB fait de la similarité vectorielle pure ; si votre cas d’usage exige « mot-clé + sémantique », il faudra composer deux systèmes de toute façon.
Ensuite, le filtrage riche. Le filtre inline de DynamoDB se limite à l’égalité stricte ; un moteur comme OpenSearch ou pgvector avec des index HNSW ou IVF offre des prédicats de plage, des facettes et des métadonnées imbriquées bien plus riches.
Enfin, le réglage du rappel. Les vector stores spécialisés laissent piloter les paramètres ANN — taille de graphe HNSW, nombre de candidats, compromis précision/latence. DynamoDB verrouille ces réglages derrière son SLA : c’est le prix de l’absence d’opérations, mais aussi une perte de contrôle pour qui optimise finement.
Où ça se place dans l’offre AWS
DynamoDB n’est pas le premier service AWS à faire de la similarité vectorielle, et il faut savoir quand préférer les autres. Amazon OpenSearch Serverless reste le choix naturel pour la recherche hybride — full-text et vectoriel combinés — et pour les cas où le reranking et les métriques de pertinence comptent. Amazon Bedrock Knowledge Bases abstrait toute la chaîne du RAG : ingestion, chunking, embeddings et récupération, sans que vous voyiez la base sous-jacente.
La nouveauté de DynamoDB, c’est d’apporter le vectoriel dans la base opérationnelle elle-même. Là où OpenSearch ajoute un cluster à administrer et Bedrock ajoute une abstraction, DynamoDB ajoute un index. Pour une équipe qui veut de la sémantique sans nouvelle brique d’infrastructure, c’est l’option la plus discrète.
Le coût caché : la consommation
Le modèle serverless a un revers : chaque SearchVectors consomme des unités de capacité, et la lecture d’un index vectoriel peut coûter nettement plus qu’un GetItem classique, car elle touche plusieurs partitions. S’y ajoute le stockage de l’index, proportionnel au nombre de vecteurs.
Avant de généraliser, mesurez sur un périmètre réel : le coût par requête, le stockage mensuel, et la facture des écritures d’embeddings — qu’il faut générer puis écrire, potentiellement en masse lors d’un backfill. Un index vectoriel mal dimensionné peut transformer une fonctionnalité « sans serveur » en facture surprise.
Verdict
Si vos données opérationnelles vivent déjà dans DynamoDB, la recherche vectorielle native est un choix évident : vous supprimez un vector store, un pipeline de synchronisation et une facture de mouvement de données, tout en gardant un modèle serverless sans machine à gérer. C’est le cas du RAG adossé à un catalogue, d’une mémoire d’agent ou d’un moteur de recommandation sur des données déjà hébergées là.
Si vous avez besoin de recherche hybride, de filtrage riche ou de rappel réglable, restez sur OpenSearch, pgvector ou un vector store spécialisé — et acceptez la charge d’exploitation qui va avec. DynamoDB ne les remplace pas sur ce terrain.
Avant d’engager un volume massif, vérifiez le prix du stockage des index vectoriels sur la page de tarification : le modèle « paiement à la requête » est séduisant, mais un index sur des milliards de vecteurs n’est pas gratuit à héberger. Le bon réflexe reste de prototyper sur un périmètre réel et de mesurer le coût par requête, pas seulement la latence.