DynamoDB vs Amazon RDS
DynamoDB et Amazon RDS sont tous deux des bases de données AWS managées, mais ils représentent deux mondes différents. DynamoDB est une base de données NoSQL clé-valeur et documentaire serverless conçue autour de patterns d'accès connus et de la montée en charge horizontale. Amazon RDS est un service managé pour faire tourner des moteurs relationnels basés sur des instances — MySQL, PostgreSQL, MariaDB, SQL Server, Oracle et Db2 — avec SQL complet, jointures et schémas appliqués.
Faut-il utiliser DynamoDB ou RDS ?
Choisis DynamoDB pour des charges opérationnelles à grande échelle avec un accès prévisible basé sur des clés, où tu veux une montée en charge serverless et aucune instance à gérer. Choisis Amazon RDS quand tu as besoin de SQL complet — jointures, requêtes ad hoc, transactions sur des tables normalisées — sur un moteur relationnel familier et que tes données tiennent dans une instance que tu peux faire monter en charge verticalement avec des réplicas en lecture. La flexibilité des requêtes face à une montée en charge sans intervention est l'arbitrage central.
DynamoDB vs Amazon RDS en un coup d'œil
| Caractéristique | DynamoDB | Amazon RDS |
|---|---|---|
| Modèle de données | NoSQL clé-valeur et documentaire ; schéma flexible par élément, éléments jusqu'à 400 Ko | Relationnel — tables, lignes et colonnes avec un schéma appliqué, sur le moteur de ton choix |
| Langage de requête | API native (GetItem, Query, Scan) plus PartiQL, un langage compatible SQL | SQL complet du moteur sous-jacent (MySQL, PostgreSQL, MariaDB, SQL Server, Oracle, Db2) |
| Jointures & relations | Pas d'opérateur JOIN ; AWS recommande de dénormaliser autour des patterns d'accès | Jointures relationnelles complètes, clés étrangères et contraintes entre les tables |
| Index | Index secondaires globaux et locaux sur une clé alternative | Les types d'index du moteur (B-tree, hash et propres au moteur), plus index partiels/d'expression sur certains moteurs |
| Cohérence | Cohérence à terme par défaut ; lectures fortement cohérentes par requête ; transactions ACID | Forte cohérence par défaut ; transactions ACID multi-instructions complètes |
| Modèle de montée en charge | Horizontale — partitionnement automatique ; le serverless à la demande monte et descend en charge (jusqu'à zéro) | Verticale — une instance provisionnée que tu redimensionnes, plus des réplicas en lecture pour l'extension en lecture |
| Provisionnement / ops | Serverless ; aucune instance à dimensionner ni à patcher | Basé sur des instances ; tu choisis la classe et le stockage, AWS gère patchs, sauvegardes et bascule (Multi-AZ en option) |
| Modèle de tarification | Paiement à la requête (à la demande) ou capacité provisionnée plus stockage ; descend jusqu'à zéro à l'inactivité | Heures-instance pour la classe de BDD plus stockage (et I/O sur certaines options), facturées tant que l'instance tourne |
| Charges idéales | Applications opérationnelles à grande échelle avec accès par clé connu (paniers, sessions, événements, classements) | Charges relationnelles et analytiques nécessitant jointures, requêtes ad hoc et forte intégrité des données |
Quand DynamoDB est le meilleur choix
- Tes patterns d'accès sont connus et basés sur des clés. Concevoir les clés autour de tes lectures donne une latence constante de l'ordre de la milliseconde, que tu aies des centaines ou des centaines de millions d'utilisateurs.
- Tu veux du serverless sans instances. La capacité à la demande n'a rien à dimensionner ni à patcher et descend jusqu'à zéro à l'inactivité — pas d'instance qui tourne en permanence.
- Tu as besoin de faire monter les écritures en charge horizontalement. DynamoDB partitionne automatiquement ; tu n'ajoutes pas d'outils de sharding comme tu le ferais pour faire monter en charge un seul primaire relationnel.
- Ta charge est orientée élément (profils, sessions, paniers, événements) plutôt qu'un réseau de tables jointes.
Quand Amazon RDS est le meilleur choix
- Tu as besoin de SQL complet et de jointures. RDS fait tourner de vrais moteurs relationnels avec jointures, agrégations, clés étrangères et requêtes ad hoc sur des tables normalisées.
- Tes patterns d'accès continuent d'évoluer. Un schéma relationnel avec des requêtes flexibles s'adapte à de nouvelles questions sans repenser les clés.
- Tu veux un moteur familier. MySQL, PostgreSQL, MariaDB, SQL Server, Oracle et Db2 permettent aux équipes de réutiliser leurs compétences, outils et SQL existants.
- Ton jeu de données tient dans une instance à montée en charge verticale avec des réplicas en lecture, et un trafic régulier intensif en requêtes convient à une instance toujours active.
Travailler avec DynamoDB
Si DynamoDB est le bon côté du choix, DynoTable est un client desktop natif pour lui sur macOS, Windows et Linux. Il lit ta chaîne d'identifiants AWS standard, donc tes données restent dans DynamoDB sans rien à migrer. Point crucial pour les équipes venant de RDS, son SQL Workbench exprime des requêtes de forme relationnelle — jointures, GROUP BY, agrégats — dans les règles de patterns d'accès de DynamoDB en les compilant vers les opérations Query/Scan propres à DynamoDB, et son assistant IA tourne sur tes propres identifiants AWS Bedrock.
Si le SQL te manque, les guides SQL pour DynamoDB et PartiQL vs SQL expliquent ce qui se transpose et ce qui ne se transpose pas, et le guide JOIN DynamoDB couvre la modélisation des relations sans jointure native. Le DynamoDB Expression Builder gratuit génère des conditions de clé, des filtres et des expressions de mise à jour corrects sous forme SDK, CLI et PartiQL. DynoTable est une application commerciale à code source fermé ; cette page décrit ce qu'elle fait, pas comment elle est construite.
FAQ
DynamoDB peut-il remplacer Amazon RDS ?
Pour certaines charges, oui. Si tes patterns d'accès sont prévisibles et basés sur des clés, DynamoDB peut remplacer une instance RDS et supprimer l'essentiel du travail de montée en charge et de patch. Il est mal adapté quand tu comptes sur les jointures, les requêtes relationnelles ad hoc ou une surface de requête en constante évolution — les forces de RDS. Beaucoup d'équipes utilisent les deux : RDS pour le travail relationnel, DynamoDB pour l'accès par clé à fort débit.
DynamoDB prend-il en charge le SQL et les jointures comme RDS ?
DynamoDB prend en charge PartiQL — un langage compatible SQL pour SELECT, INSERT, UPDATE et DELETE — mais il n'a pas d'opérateur JOIN ; AWS recommande plutôt de dénormaliser. Les moteurs derrière RDS prennent en charge le SQL complet, jointures entre tables incluses. Consulte Jointures dans DynamoDB pour savoir comment modéliser les relations sans jointure.
DynamoDB est-il moins cher que RDS ?
Ça dépend de la charge de travail, alors modélise les deux. DynamoDB facture par requête (ou capacité provisionnée) plus le stockage et descend jusqu'à zéro à l'inactivité, ce qui convient à un trafic en pics ou à faible base. RDS facture des heures-instance pour une classe active plus le stockage, ce qui peut être plus rentable pour des charges régulières et intensives en requêtes. Estime face à tes vrais patterns d'accès avant de décider.
Voir aussi
- Apprends SQL pour DynamoDB, PartiQL vs SQL et les jointures dans DynamoDB.
- Modélise les données autour des patterns d'accès avec comment modéliser des données dans DynamoDB.
- Construis des requêtes rapidement avec le DynamoDB Expression Builder gratuit.
- Télécharger DynoTable pour macOS, Windows ou Linux.
Dernière vérification le 2026-07-12 par rapport à la documentation officielle AWS DynamoDB et Amazon RDS. Amazon RDS et DynamoDB sont des services d'Amazon Web Services ; mentionnés ici à des fins d'identification uniquement.