DynamoDB vs MongoDB
Devrais-tu utiliser DynamoDB ou MongoDB ?
Choisis DynamoDB pour un magasin clé-valeur et document serverless entièrement managé sur AWS avec des modèles d'accès par clé prévisibles et une montée en charge sans intervention. Choisis MongoDB pour une base de données document avec des requêtes ad hoc flexibles, un riche pipeline d'agrégation, et la possibilité d'auto-héberger ou d'exécuter en managé sur n'importe quel grand cloud. Ce sont tes modèles d'accès qui tranchent.
DynamoDB vs MongoDB en un coup d'œil
| Caractéristique | DynamoDB | MongoDB |
|---|---|---|
| Modèle de données | NoSQL clé-valeur et document ; éléments regroupés dans des tables, chaque élément jusqu'à 400 KB | Base de données document ; documents BSON (type JSON) jusqu'à 16 MB, regroupés en collections |
| Langage de requête / API | API native (GetItem, Query, Scan, PutItem, …) plus PartiQL, un langage de requête compatible SQL | MongoDB Query API (MQL) plus le pipeline d'agrégation pour les transformations multi-étapes, jointures ($lookup) et regroupement |
| Modèle d'accès principal | Recherches par clé sur la clé de partition (et clé de tri optionnelle) ; le schéma est conçu à l'avance autour de modèles d'accès connus | Requêtes flexibles sur n'importe quel champ ; filtres et agrégations ad hoc, adossés à des index |
| Index secondaires | Index secondaires globaux (débit propre, toute clé) et index secondaires locaux (même clé de partition, plafond de 10 GB par partition) | Index secondaires sur n'importe quel champ, y compris composés, multiclés, texte, géospatiaux et wildcard |
| Modèle de cohérence | Lectures à terme par défaut ; lectures fortement cohérentes disponibles par requête (au sein d'une seule Région AWS) | Read/write concerns ajustables ; les lectures depuis le primaire sont fortement cohérentes par défaut |
| Modèle de montée en charge | Partitionnement automatique géré par AWS ; monte le débit et le stockage sans provisionner de serveurs | Montée en charge horizontale via le sharding sur un cluster ; les replica sets assurent la haute disponibilité et le basculement |
| Transactions | Transactions ACID sur plusieurs éléments, limitées à une seule Région AWS | Transactions ACID multi-documents (depuis 4.0), y compris entre shards (depuis 4.2) |
| Modèle tarifaire | Paiement à la requête (on-demand) ou capacité provisionnée, plus le stockage ; aucun serveur à gérer | Atlas est basé sur des clusters (taille/heures d'instance) avec un palier Flex à faible coût ; l'édition Community auto-hébergée n'a que le coût d'infrastructure |
| Options managé / serverless | Entièrement serverless et entièrement managé ; disponible uniquement sur AWS | Service managé Atlas sur AWS, Google Cloud ou Azure ; également auto-hébergeable. Les instances Atlas Serverless ont été retirées et remplacées par le palier Flex |
| Charges de travail idéales | Applications à grande échelle avec accès par clé prévisible nécessitant une faible latence constante et un minimum d'opérations | Applications à schémas évolutifs, requêtes ad hoc et riches agrégations, ou nécessitant une portabilité multi-cloud / on-prem |
Quand DynamoDB est le meilleur choix
- Tu es sur AWS et veux zéro opération de base de données. DynamoDB est serverless — il n'y a ni instances, ni clusters, ni capacité à patcher. Le mode on-demand s'adapte automatiquement au trafic (modes de capacité).
- Tes modèles d'accès sont connus et basés sur des clés. Quand tu peux concevoir tes clés autour de la façon dont tu lis les données, DynamoDB délivre des recherches à faible latence constantes à pratiquement n'importe quelle échelle. C'est là que le single-table design brille.
- Tu veux une tarification au paiement à la requête. Avec la capacité on-demand, tu ne paies que les lectures et écritures que tu effectues, sans coût de cluster inactif.
- Tu as besoin d'une intégration AWS étroite. Les liens natifs avec IAM, Lambda, les streams et l'écosystème AWS plus large réduisent le code de liaison.
Quand MongoDB est le meilleur choix
- Tes requêtes sont ad hoc ou exploratoires. MongoDB te permet de filtrer et d'indexer sur n'importe quel champ et d'exécuter de riches agrégations côté serveur — y compris des jointures entre collections — sans planifier à l'avance chaque modèle d'accès.
- Tu as besoin de portabilité entre clouds ou on-prem. MongoDB s'exécute auto-hébergé ou sur Atlas sur AWS, Google Cloud et Azure. DynamoDB est réservé à AWS.
- Tes documents sont volumineux ou profondément imbriqués. Le plafond de 16 MB par document de MongoDB est bien plus grand que la limite de 400 KB par élément de DynamoDB (contraintes DynamoDB).
- Ton schéma évolue rapidement. Des documents flexibles plus une indexation secondaire de première classe conviennent aux modèles qui changent vite sans conception de clés rigide en amont.
Travailler avec DynamoDB
Une fois DynamoDB choisi, tu as toujours besoin d'un moyen rapide de parcourir les tables, exécuter des requêtes et modifier des éléments au quotidien. DynoTable est une interface graphique de bureau native pour DynamoDB : parcourir et modifier des éléments en ligne, construire des conditions de clé et des filtres, et interroger avec un SQL workbench et un assistant IA. Si tu viens du modèle mental « tout interroger » de MongoDB, le SQL workbench t'aide à exprimer des requêtes de forme relationnelle tout en restant dans les règles de modèle d'accès de DynamoDB.
Pour construire des expressions sans quitter la documentation, le DynamoDB Expression Builder gratuit génère des expressions de condition de clé, de filtre et de mise à jour avec une sortie SDK, CLI et PartiQL prête à coller. Et si tu débutes en modélisation pour un magasin clé-valeur, le guide comment modéliser des données dans DynamoDB explique comment traduire des entités et des modèles d'accès en clés.
FAQ
DynamoDB est-il plus rapide que MongoDB ?
Aucun n'est universellement plus rapide — cela dépend de la charge de travail et de la façon dont les données sont modélisées. DynamoDB est conçu pour délivrer des performances à faible latence constantes à grande échelle pour l'accès par clé, tandis que MongoDB peut être très rapide pour les requêtes indexées et ad hoc. Le bon modèle de données compte plus que le moteur pour la latence réelle.
DynamoDB peut-il remplacer MongoDB ?
Parfois. Si tes modèles d'accès sont prévisibles et basés sur des clés, DynamoDB peut remplacer MongoDB et supprimer la plupart de la charge opérationnelle. Si tu dépends de requêtes ad hoc ou d'agrégations côté serveur sur de nombreux champs, une migration signifie d'abord remodéliser tes données autour des clés de DynamoDB — voir comment modéliser des données dans DynamoDB.
DynamoDB est-il basé sur MongoDB ?
Non. Ce sont des produits sans lien issus d'entreprises différentes. DynamoDB est une base de données managée par AWS dont la lignée de conception remonte aux travaux internes Dynamo d'Amazon, tandis que MongoDB est une base de données document distincte, d'origine open source. Ils partagent l'étiquette « NoSQL » mais aucun code.
Voir aussi
- Apprends le single-table design et comment modéliser des données dans DynamoDB.
- Construis des expressions avec le DynamoDB Expression Builder gratuit.
- Télécharger DynoTable pour parcourir, interroger et modifier DynamoDB avec un SQL workbench et l'IA.
Dernière vérification le 2026-07-12 par rapport à l'AWS DynamoDB Developer Guide officiel et à la documentation MongoDB. MongoDB est une marque déposée de son propriétaire respectif ; mentionnée ici à des fins d'identification uniquement.