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

Oui. DynamoDB est une base de données NoSQL — un magasin clé-valeur et document non relationnel et entièrement managé. Il contient des éléments sans schema plutôt que des lignes dans des tables à schema fixe, et échange les jointures SQL et les requêtes ad hoc contre des performances prévisibles de quelques millisecondes à un chiffre et une montée en charge horizontale à pratiquement n'importe quelle taille.

Quel genre de NoSQL

DynamoDB prend en charge à la fois le modèle de données clé-valeur et le modèle document. Chaque élément est adressé par une clé primaire, et les attributs peuvent s'imbriquer en maps et en listes jusqu'à 32 niveaux de profondeur — c'est le versant document du modèle.

En quoi il diffère de SQL

Pas de schema fixe — seule la clé primaire est définie à l'avance ; les autres attributs varient d'un élément à l'autre.
Pas de jointures — tu dénormalises et tu modélises autour des modèles d'accès à la place.
Performances prévisibles — les lectures visent une clé de partition, si bien que la latence reste plate quand les données grossissent.

Ce que le moteur fait d'un JOIN

PartiQL donne à DynamoDB une allure SQL, et la frontière est donc facile à manquer. La syntaxe SELECT documentée par AWS est toute la grammaire, et elle ne comporte aucune clause JOIN :

SELECT {{expression}}  [, ...]
FROM {{table}}[.{{index}}]
[ WHERE {{condition}} ] [ [ORDER BY {{key}} [DESC|ASC] , ...]

Envoies-en une quand même et le parseur s'arrête à la deuxième table :

await client.send(
  new ExecuteStatementCommand({
    Statement: `SELECT o.pk FROM "orders" o JOIN "customers" c ON o.pk = c.pk`
  })
);

Sortie réelle :

ValidationException: Only select from a single table or index is supported.
HTTP 400

Le refus a lieu au moment de l'analyse, avant qu'aucune donnée ne soit lue : c'est pour ça qu'aucune conception d'index ne te donnera de jointure. Joindre, c'est le travail de ton application dans un magasin NoSQL.

Ça borne aussi ce que n'importe quel client peut honnêtement proposer. Le SQL Workbench de DynoTable accepte INNER JOIN, LEFT JOIN, GROUP BY et COUNT/SUM/AVG/MIN/MAX.

Il les compile vers des appels Query et Scan natifs, puis joint et agrège les résultats sur ta machine. DynamoDB, lui, ne voit jamais que des lectures sur une seule table.

Quand ça convient

DynamoDB est conçu pour les charges de travail OLTP : lectures et écritures ponctuelles ou par plage, connues d'avance et à gros volume. L'analytique lourde a sa place dans un magasin colonne séparé, alimenté par export.

Les limites NoSQL qui se sentent quand même en production

« NoSQL » décrit le modèle d'accès, pas la disparition des contraintes. DynamoDB te plafonne toujours à 400 Ko par élément, 25 actions par TransactWriteItems et 100 actions de lecture ou d'écriture par transaction. Un document imbriqué peut descendre à 32 niveaux. Les GSI ne projettent que les attributs que tu nommes ; il n'y a aucun schema caché sur lequel se rabattre.

Ces limites comptent parce qu'aucune jointure ne t'en sortira au moment de la requête. Tu modélises autour d'elles en amont — index creux, attributs dénormalisés et clés de table unique — puis tu lis par partition. Le query builder transforme un filtre en la requête Query ou Scan que DynamoDB exécutera réellement.

Dans DynoTable : quand une question relationnelle est légitime, le SQL Workbench compile JOIN et GROUP BY vers des appels Query et Scan natifs sur ta machine — DynamoDB, lui, ne voit toujours que des lectures sur une seule table. Vois SQL Workbench pour la grammaire prise en charge et ses limites honnêtes.

Aller plus loin

Vois quand utiliser DynamoDB et comment façonner tes données avec comment modéliser des données dans DynamoDB. Télécharge DynoTable pour parcourir tes tables NoSQL et exécuter du SQL dessus, dans les règles de modèle d'accès de DynamoDB.

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus ; la grammaire SELECT de PartiQL a été revérifiée le 2026-07-28.

Reproduit le 2026-07-28 sur DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 sur Node v24.18.0. La ValidationException ci-dessus est la sortie du moteur, telle quelle.