DynamoDB vs Google Cloud Spanner
DynamoDB et Google Cloud Spanner montent tous deux en charge horizontalement sur un cluster distribué, mais ils font des paris fondamentaux opposés. DynamoDB est un magasin NoSQL clé-valeur et documentaire serverless d'AWS conçu autour de patterns d'accès connus. Spanner est une base de données relationnelle distribuée mondialement qui conserve le SQL complet et des transactions fortes (à cohérence externe) même entre régions, en utilisant l'horloge TrueTime de Google.
Faut-il utiliser DynamoDB ou Spanner ?
Choisis DynamoDB si tu es sur AWS et que tu veux un magasin NoSQL serverless avec une facturation à la requête et une latence prévisible pour l'accès par clé. Choisis Google Cloud Spanner si tu as besoin de SQL relationnel, de jointures et d'une forte cohérence transactionnelle à l'échelle mondiale — une base de données à montée en charge horizontale qui se comporte toujours comme une base relationnelle. Les garanties relationnelles à l'échelle face à la simplicité NoSQL serverless est l'axe décisif.
DynamoDB vs Spanner en un coup d'œil
| Caractéristique | DynamoDB | Google Cloud Spanner |
|---|---|---|
| Modèle de données | NoSQL clé-valeur et documentaire ; schéma flexible par élément, éléments jusqu'à 400 Ko | Relationnel — tables, lignes, colonnes et schémas (expose aussi des capacités de graphe, clé-valeur et recherche) |
| Langage de requête | API native (GetItem, Query, Scan) plus PartiQL, un langage compatible SQL | SQL complet dans deux dialectes — GoogleSQL et un dialecte compatible PostgreSQL |
| 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 tables imbriquées |
| Cohérence | Cohérence à terme par défaut ; lectures fortement cohérentes par requête (au sein d'une région) | Cohérence externe (forte) par défaut, y compris entre régions, appuyée par l'horloge TrueTime |
| Transactions | Transactions ACID sur plusieurs éléments au sein d'une région | Transactions ACID cohérentes à l'échelle mondiale, y compris entre régions |
| Modèle de montée en charge | Partitionnement automatique ; capacité serverless à la demande ou provisionnée | Montée en charge horizontale via du compute provisionné (nœuds / unités de traitement) avec autoscaling ; le stockage monte en charge séparément |
| Multi-région | Global Tables — réplication multi-région active-active (cohérence à terme entre régions) | Configurations multi-région qui préservent la forte cohérence entre régions |
| Modèle tarif / ops | Paiement à la requête (à la demande) ou capacité provisionnée plus stockage ; serverless, AWS uniquement | Capacité de compute provisionnée plus stockage (et réseau) ; basé sur nœuds/unités de traitement, GCP uniquement |
| Charges idéales | Applications opérationnelles à grande échelle avec accès par clé connu nécessitant une faible latence constante | Systèmes relationnels mondiaux nécessitant forte cohérence, SQL et jointures à l'échelle |
Quand DynamoDB est le meilleur choix
- Tu es sur AWS et veux du NoSQL serverless. La capacité à la demande n'a rien à provisionner, s'adapte au trafic et descend jusqu'à zéro à l'inactivité.
- Tes patterns d'accès sont connus et basés sur des clés. Le modèle clé de partition / clé de tri de DynamoDB donne une latence constante de l'ordre de la milliseconde quand les clés sont conçues autour de tes lectures.
- Tu n'as pas besoin de jointures relationnelles ni de forte cohérence mondiale. Si un modèle dénormalisé et orienté clé convient, tu évites de payer pour des garanties que tu n'utiliseras pas.
- Tu veux une intégration AWS native avec IAM, Lambda et Streams.
Quand Spanner est le meilleur choix
- Tu as besoin de SQL relationnel à l'échelle mondiale. Spanner conserve les jointures, les schémas et le SQL complet tout en montant en charge horizontalement — tu n'abandonnes pas la sémantique relationnelle pour t'étendre.
- Tu as besoin de forte cohérence entre régions. La cohérence externe appuyée par TrueTime permet aux transactions multi-région de se comporter comme si elles étaient sérialisées, ce que les Global Tables de DynamoDB (cohérence à terme entre régions) n'offrent pas.
- Ta charge est relationnelle et flexible en requêtes. Les jointures ad hoc et les requêtes évolutives sur des tables normalisées conviennent au modèle de Spanner.
- Tu es sur GCP et veux sa base de données mondiale managée avec des SLA de haute disponibilité.
Travailler avec DynamoDB
Si DynamoDB convient, 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. Pour les équipes habituées au SQL de Spanner, 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 Query/Scan de DynamoDB, et son assistant IA tourne sur tes propres identifiants AWS Bedrock.
Les guides SQL pour DynamoDB et PartiQL vs SQL expliquent ce qui se transpose depuis SQL, et le DynamoDB Expression Builder gratuit génère des conditions de clé, des filtres et des expressions de mise à jour 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
Spanner est-il une base de données NoSQL comme DynamoDB ?
Non. Spanner est une base de données relationnelle avec SQL complet, jointures et schémas qui se trouve monter en charge horizontalement comme un système distribué. DynamoDB est un magasin NoSQL clé-valeur et documentaire sans opérateur JOIN. La revendication distinctive de Spanner est de conserver une sémantique relationnelle et fortement cohérente à l'échelle mondiale.
DynamoDB offre-t-il une forte cohérence mondiale comme Spanner ?
Pas de la même façon. DynamoDB fournit des lectures fortement cohérentes au sein d'une seule région, et les Global Tables répliquent entre régions mais avec une cohérence à terme entre elles. Spanner utilise TrueTime pour fournir une cohérence externe (forte) pour les transactions même entre régions.
DynamoDB peut-il remplacer Spanner ?
Seulement quand tu n'as pas besoin de SQL relationnel ni de forte cohérence mondiale. Si ton accès est basé sur des clés et qu'un modèle dénormalisé convient, DynamoDB est plus simple et serverless. Si tu comptes sur les jointures, le SQL ad hoc ou des transactions inter-régions fortement cohérentes, c'est la raison d'être de Spanner — le remplacer signifie remodeler tes données autour des clés de DynamoDB et abandonner ces garanties.
Voir aussi
- Apprends la cohérence DynamoDB et les Global Tables multi-région.
- Vois ce qui se transpose dans SQL pour DynamoDB et PartiQL vs SQL.
- Construis des requêtes rapidement avec le DynamoDB Expression Builder gratuit.
- Télécharger DynoTable pour travailler avec tes tables DynamoDB.
Dernière vérification le 2026-07-12 par rapport à l'AWS DynamoDB Developer Guide officiel et à la documentation Google Cloud Spanner. Google Cloud Spanner est une marque de Google LLC ; mentionnée ici à des fins d'identification uniquement.