DynamoDB est-il une base de données relationnelle ?

Non. DynamoDB n'est pas une base de données relationnelle — c'est un magasin NoSQL clé-valeur et document. Il n'y a pas de tables à schéma fixe, pas de clés étrangères, pas de jointures. Tu modélises les données autour des modèles d'accès de ton application et tu dénormalises, au lieu de normaliser entre des tables liées comme tu le ferais dans une base relationnelle (SQL). Si le workflow relationnel te manque, DynoTable en ramène une partie côté client : un SQL Workbench qui exécute de vrais JOIN et GROUP BY, et des Smart Tables qui joignent les tables visuellement.

Pourquoi ce n'est pas relationnel

Les bases relationnelles imposent un schéma, normalisent les données sur de nombreuses tables et les joignent à la lecture. DynamoDB fait l'inverse : il stocke des éléments sans schéma et attend de toi que tu pré-joignes en dupliquant ou en imbriquant les données liées.

Ce qui remplace les fonctionnalités relationnelles

Les jointures → dénormalisation et single-table design.
Les tables normalisées → collections d'éléments regroupées sous une même clé de partition.
Le SQL ad hoc → Query et Scan par clé, ou PartiQL (un sous-ensemble compatible SQL, toujours sans jointures).

PartiQL ne comble d'ailleurs pas l'écart. Son analyseur rejette un SELECT sur deux tables et rejette GROUP BY, tous deux avant de lire quoi que ce soit ; les refus exacts sont cités sur DynamoDB prend-il en charge les jointures et DynamoDB prend-il en charge SQL.

Ce que la dénormalisation te coûte vraiment

On décrit d'habitude le compromis comme « dupliquer les données au lieu de joindre », ce qui sonne comme une décision de stockage. C'est en réalité une décision d'écriture et d'atomicité, et c'est la partie que les moteurs relationnels te cachent.

Prends un client avec 5 000 commandes, et le client change son nom d'affichage. Dans un schéma relationnel, c'est un UPDATE sur une ligne, et chaque jointure reprend immédiatement la nouvelle valeur. Dénormalisé dans DynamoDB, le nom vit sur les 5 000 éléments de commande : le renommage, c'est donc 5 000 écritures d'éléments, soit 5 000 unités d'écriture, environ $0.003 en on-demand us-east-1 à 1 Ko par élément.

L'argent n'est rien. Le problème, c'est que ça ne peut pas être une seule opération. TransactWriteItems plafonne à 100 actions, donc 5 000 éléments font au moins 50 transactions distinctes, et il n'y a aucune isolation entre elles. Tant que cet éventail tourne, tes propres données se contredisent, et toute lecture qui tombe en plein vol voit un mélange d'anciens et de nouveaux noms.

Les bases relationnelles t'achètent exactement ça : un changement atomique sur une copie faisant autorité. Y renoncer est le vrai prix d'entrée, et c'est pourquoi « quels attributs sont dupliqués » mérite plus d'attention de conception que « lesquels sont indexés ».

Aller plus loin

Lis comment modéliser des données dans DynamoDB et le single-table design. Télécharge DynoTable pour explorer visuellement ton modèle de données — et y lancer des requêtes JOIN/GROUP BY de style relationnel avec le SQL Workbench.

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus ; le plafond de 100 actions par transaction a été revérifié dans la référence de l'API le 2026-07-28.