DynamoDB est-il sans schéma ?

Oui. DynamoDB est sans schéma. En dehors de la clé primaire, tu ne définis aucun attribut ni type de données à la création d'une table. Chaque élément peut porter son propre jeu d'attributs, et ceux-ci peuvent varier librement d'un élément à l'autre — tu adaptes donc ton modèle de données sans lancer de migration de schéma.

Ce que tu définis à l'avance

Uniquement la clé primaire : une clé de partition (obligatoire) et une clé de tri optionnelle, plus leurs types. Tout le reste est arbitraire. Tu ne déclares pas de colonnes.

Ce qui varie par élément

Deux éléments quelconques d'une même table peuvent avoir des attributs complètement différents. L'un peut contenir email et status ; l'autre orderTotal et une map address imbriquée. DynamoDB stocke ce que tu écris, point.

Là où le sans-schéma s'arrête

Le sans-schéma a une frontière précise. La clé primaire est validée à chaque écriture ; rien d'autre ne l'est. Deux éléments sans aucun attribut en commun entrent dans la même table sans la moindre plainte :

await client.send(
  new PutItemCommand({
    TableName: 'people',
    Item: {pk: {S: 'USER#1'}, email: {S: 'a@b.c'}, status: {S: 'active'}}
  })
);
await client.send(
  new PutItemCommand({
    TableName: 'people',
    Item: {
      pk: {S: 'ORDER#1'},
      orderTotal: {N: '42.5'},
      address: {M: {city: {S: 'Madrid'}}},
      tags: {SS: ['a', 'b']}
    }
  })
);

Les deux réussissent. Maintenant, écris la même clé de partition sous forme de nombre plutôt que de chaîne :

ValidationException: One or more parameter values were invalid: Type mismatch for key
HTTP 400

Et omets complètement pk :

ValidationException: One of the required keys was not given a value
HTTP 400

Ces deux rejets constituent tout le schéma. L'attribut de clé doit être présent et doit correspondre au type déclaré dans AttributeDefinitions. Tout ce qui va au-delà est accepté tel quel.

Une faute de frappe passe elle aussi. Rien ne te dit à l'écriture que staus devait être status.

En quoi ça aide

Pas de migrations — ajoute ou retire des attributs quand tu veux.
Entités mixtes — de nombreux types d'entités peuvent partager une table (single-table design).
Évolutif — le modèle change en même temps que les besoins.

Le compromis : c'est ton application, pas la base de données, qui impose la forme dont tu dépends.

Ce que le sans-schéma n'assouplit pas

Le sans-schéma ne concerne que les attributs hors clé. Toutes les autres limites de DynamoDB continuent de s'appliquer :

400 Ko par élément — noms et valeurs d'attributs comptent tous les deux dans le plafond.
32 niveaux d'imbrication pour les maps et les listes à l'intérieur d'une valeur.
65 535 octets de longueur maximale pour un nom d'attribut.
25 éléments au maximum par appel BatchWriteItem.

Tu peux poser une chaîne status sur un élément et l'omettre sur le suivant, mais tu ne peux stocker un blob de 500 Ko ni dans l'un ni dans l'autre. Utilise le calculateur de taille d'élément pour mesurer une charge utile avant de l'écrire, et lis la conception à table unique quand tu mélanges des types d'entités dans une même table.

Dans DynoTable : ouvre Réglages sur n'importe quelle table et indexe-la. Le schema inféré est construit à partir d'éléments échantillonnés et étiqueté honnêtement — il montre ce que tu as écrit, pas ce que tu as déclaré. Vois Vue d'ensemble et indexation de la table pour savoir comment l'index local échantillonne et se rafraîchit.

Aller plus loin

Voir le single-table design et le motif de l'attribut type pour les éléments mixtes. Télécharge DynoTable pour inspecter les formes réelles de tes éléments.

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.

Reproduit le 2026-07-28 sur DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 sur Node v24.18.0. Les deux messages ValidationException sont la sortie brute du moteur.