DynamoDB vs Firestore
DynamoDB ou Firestore, lequel est meilleur pour mon application ?
Les deux sont des bases de données NoSQL serverless entièrement managées, mais elles résolvent des problèmes différents. Amazon DynamoDB est un magasin clé-valeur et document AWS optimisé pour un accès prévisible à faible latence à grande échelle. Google Cloud Firestore est une base de données document GCP dont la caractéristique distinctive est les écouteurs de snapshot en temps réel et les SDK mobiles et web capables de fonctionner hors ligne. Choisis DynamoDB pour des backends natifs AWS ; choisis Firestore pour des applications temps réel connectées au client.
| Caractéristique | DynamoDB | Firestore |
|---|---|---|
| Plateforme cloud | Amazon Web Services (AWS) | Google Cloud / Firebase (GCP) |
| Modèle de données | Tables d'éléments (clé-valeur et document) ; attributs sur chaque élément | Documents regroupés en collections ; les documents contiennent des champs imbriqués et des sous-collections |
| API de requête | Query/Scan via le SDK AWS, la CLI ou PartiQL ; accès piloté par la clé primaire et les index | Requêtes document/collection via les SDK client et serveur, avec filtres chaînés et tri |
| Synchro temps réel et hors ligne | Pas de synchro client native ; la capture de changements passe par DynamoDB Streams, consommés par ton propre code (ex. Lambda) | Écouteurs de snapshot en temps réel intégrés ; persistance hors ligne et cache local dans les SDK Apple, Android et web |
| Index | Index secondaires globaux (GSI) et index secondaires locaux (LSI), définis explicitement | Index à champ unique automatiques plus index composites explicites pour les requêtes multi-champs |
| Cohérence | Lectures à terme par défaut ; lectures fortement cohérentes en option (et sur les LSI) ; les lectures GSI sont uniquement à terme | Requêtes fortement cohérentes |
| Montée en charge | Serverless ; débit on-demand ou provisionné ; global tables pour la réplication multi-Région | Serverless avec mise à l'échelle automatique et réplication multi-région |
| Modèle tarifaire | Unités de capacité de lecture/écriture (RCU/WCU) — provisionnées ou on-demand — plus le stockage | Par lecture, écriture et suppression de document, plus le stockage, la sortie réseau et les entrées d'index lues ; quota quotidien gratuit |
| Meilleur usage | Backends natifs AWS à grande échelle avec des modèles d'accès bien définis | Applications temps réel, mobile-first et connectées au client sur GCP/Firebase |
Quand DynamoDB est le meilleur choix
DynamoDB convient quand ta stack est sur AWS et que tu veux une base de données qui reste rapide et prévisible à mesure que le trafic augmente. Son modèle de capacité (RCU/WCU, provisionné ou on-demand) et son accès de quelques millisecondes conviennent aux backends à fort débit — paniers d'achat, magasins de sessions, journalisation d'événements, et toute charge de travail dont les modèles d'accès sont bien compris et que tu peux modéliser autour d'une clé primaire plus des GSI.
C'est aussi le meilleur choix quand tu as besoin de lectures fortement cohérentes sur ta table primaire, d'un contrôle d'accès strict basé sur IAM, ou d'une intégration avec l'écosystème AWS plus large (Lambda, export S3, streams vers l'analytique). Si tes clients communiquent avec ta propre API plutôt que directement avec la base de données, l'absence de couche de synchro client intégrée dans DynamoDB n'est pas une limitation.
Quand Firestore est le meilleur choix
Firestore est l'option la plus forte pour les applications temps réel et mobile-first. Ses écouteurs de snapshot poussent les changements vers les clients connectés dès que les données sont mises à jour, et ses SDK Apple, Android et web mettent les données en cache localement pour que l'application continue de fonctionner hors ligne et se resynchronise lorsque l'appareil se reconnecte. Cela en fait un choix naturel pour le chat, les outils collaboratifs, les tableaux de bord en direct et les applications mobiles grand public.
C'est aussi un bon choix par défaut quand tu es déjà sur Google Cloud ou Firebase, que tu veux des requêtes fortement cohérentes sans opter par requête, ou que tu préfères laisser les clients interroger directement la base de données (protégée par des règles de sécurité) au lieu de construire une couche d'API. Son indexation automatique élimine une partie du travail initial de conception de schéma à petite échelle.
Travailler avec DynamoDB
Une fois DynamoDB choisi, DynoTable est un client de bureau pour travailler directement avec tes tables — parcourir et modifier des éléments, exécuter des requêtes et construire des expressions sans écrire chaque requête à la main. Il lit tes identifiants AWS standard et communique avec DynamoDB dans ton propre compte.
Si tu assembles encore les requêtes à la main, le DynamoDB Expression Builder gratuit génère des conditions de clé, des expressions de filtre et des expressions de mise à jour avec les espaces réservés de nom et de valeur d'attribut corrects pour le SDK AWS, la CLI, boto3 et PartiQL. DynoTable est une application commerciale à code fermé ; cette page est une comparaison technique neutre, pas un benchmark.
FAQ
Dois-je utiliser DynamoDB ou Firestore pour une application mobile ?
Pour une application mobile qui a besoin de mises à jour en temps réel ou d'un support hors ligne, Firestore est généralement le choix le plus direct : ses SDK Apple, Android et web incluent des écouteurs de snapshot en temps réel et la persistance hors ligne prêts à l'emploi. DynamoDB n'a pas de couche de synchro client native — tu construirais le comportement temps réel toi-même en utilisant DynamoDB Streams et ton propre backend. DynamoDB convient mieux quand les clients appellent ta propre API plutôt que la base de données directement.
Lequel est le moins cher, DynamoDB ou Firestore ?
Aucun n'est universellement moins cher ; ils facturent sur des axes différents. DynamoDB facture les unités de capacité de lecture/écriture (provisionnées ou on-demand) plus le stockage, donc le coût suit le débit. Firestore facture par lecture, écriture et suppression de document, plus le stockage, la sortie réseau et les entrées d'index lues, avec un quota quotidien gratuit. Les charges de travail à forte lecture ou à forts écouteurs temps réel peuvent accumuler des frais de lecture de document Firestore, tandis que les charges à fort débit régulier se modélisent souvent de façon plus prévisible sur DynamoDB. Estime selon ton propre modèle d'accès en utilisant la page de tarification actuelle de chaque fournisseur.
DynamoDB dispose-t-il d'une synchronisation en temps réel comme Firestore ?
Pas nativement côté client. Les écouteurs de snapshot de Firestore diffusent automatiquement les changements vers les applications connectées. L'équivalent de DynamoDB est DynamoDB Streams, qui capture les changements au niveau de l'élément ; tu consommes ce flux avec ton propre code (par exemple une fonction AWS Lambda) pour propager les mises à jour. C'est une capture de changements en temps réel, mais tu construis toi-même la livraison aux clients.
Voir aussi
- Apprends quand utiliser DynamoDB pour les modèles d'accès auxquels il convient le mieux.
- Comprends DynamoDB Streams — le mécanisme de capture de changements derrière tout pipeline temps réel.
- Construis des requêtes visuellement avec le DynamoDB Expression Builder.
- Télécharger DynoTable pour travailler avec tes tables DynamoDB sur macOS, Windows ou Linux.
Dernière vérification le 2026-07-12 par rapport à l'AWS DynamoDB Developer Guide et à la documentation de Google Cloud Firestore. Google Cloud Firestore est une marque déposée de son propriétaire respectif ; mentionnée ici à des fins d'identification uniquement.