Quand ne faut-il pas utiliser DynamoDB ?

Évite DynamoDB quand ta charge de travail est analytique ou que tes modèles d'accès sont inconnus. DynamoDB est conçu spécifiquement pour les charges opérationnelles (OLTP) avec des modèles d'accès connus et basés sur des clés — il n'a ni jointures ni fonctions d'agrégation, et les requêtes ad hoc retombent sur des scans de table complets coûteux. Pour du reporting OLAP ou des besoins relationnels qui évoluent, choisis un autre moteur.

Mauvaises adéquations

Analytique et reporting ad hoc (OLAP) — il n'y a ni GROUP BY, ni SUM, ni AVG ; chaque agrégation est un scan ou un agrégat pré-calculé que tu maintiens toi-même. Voir le guide d'agrégation pour les contournements.
Schémas relationnels normalisés — DynamoDB omet délibérément l'opérateur JOIN ; la recommandation d'AWS elle-même est de dénormaliser.
Modèles d'accès inconnus ou en évolution rapide — tu conçois les clés autour des requêtes. Quand tu ne peux pas encore nommer les requêtes, chaque nouvelle risque une refonte de la table ou un scan complet.
Recherche plein texte et interrogation riche — voir DynamoDB prend-il en charge la recherche plein texte ? ; la recherche appartient à un index de recherche.
Objets volumineux — les éléments plafonnent à 400 Ko ; les médias et documents appartiennent à S3, avec un pointeur dans la table.

L'agrégation, refusée puis chiffrée

L'inadéquation analytique n'est pas une affaire de goût. Demande à DynamoDB un décompte groupé en PartiQL et l'instruction est rejetée avant de lire quoi que ce soit :

SELECT status, COUNT(*) FROM "orders" GROUP BY status

ValidationException: Unsupported clause: GROUP BY
HTTP 400

Enlève le regroupement et demande le simple total : ça échoue une étape plus tôt, dans l'analyseur :

SELECT COUNT(*) FROM "orders"

ValidationException: Unexpected path component at 1:8:5
HTTP 400

COUNT n'est tout simplement pas une fonction dans ce dialecte : l'analyseur le lit donc comme un chemin d'attribut et abandonne à la parenthèse.

Reste le Scan que tu écris toi-même, et il a un prix. Lire une table de 50 Go de bout en bout coûte 6 553 600 unités de lecture en cohérence à terme, soit la taille cumulée scannée en unités de 4 Ko, divisée par deux. En on-demand dans us-east-1, ça fait 0,82 $.

Rafraîchis ce seul chiffre toutes les heures et ça fait $598 par mois. Maintenir le compteur au fil des écritures, ou exporter vers un magasin analytique, est la réponse la moins chère, et ce sont deux travaux que DynamoDB ne fait pas pour toi.

Là où il brille

La liste inverse est exactement le point fort de DynamoDB : des charges opérationnelles à fort volume, avec des lectures et écritures par clé prévisibles qui doivent rester à quelques millisecondes à n'importe quelle échelle — paniers, sessions, profils, état de jeu, événements IoT. Le guide sur quand utiliser DynamoDB présente l’argument inverse.

Aller plus loin

Si tu hésites, lis ensuite quand utiliser DynamoDB. Déjà sur DynamoDB et SQL te manque ? DynoTable exécute JOIN et GROUP BY sur des tables en production, depuis le bureau — et le calculateur de tarifs te dit ce que coûterait ta charge avant que tu ne t'engages.

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus. Le chiffre de 400 Ko a été reconfirmé le 2026-07-28 ; AWS l'a déplacé de la page des quotas de service vers Constraints.html.

Reproduit le 2026-07-28 contre DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 sur Node v24.18.0 ; les deux messages ValidationException sont cités tels quels. Le coût du Scan est calculé à partir des tarifs us-east-1 de notre table tarifaire AWS synchronisée.