DynamoDB peut-il stocker des tableaux ?

Oui. DynamoDB stocke les tableaux avec le type Liste (L) — une collection ordonnée qui peut contenir des types mixtes : chaînes, nombres, booléens, nuls, maps et listes imbriquées. Pour des collections non ordonnées de valeurs uniques, il propose aussi des ensembles de chaînes, de nombres et binaires. Il n'y a pas de limite au nombre d'éléments tant que l'élément reste sous 400 Ko.

Listes (tableaux ordonnés)

Une Liste préserve l'ordre et accepte les doublons et les types mixtes. Elle correspond directement à un tableau JSON et peut s'imbriquer (listes de maps, listes de listes) jusqu'à 32 niveaux de profondeur.

Cette limite documentée compte la valeur tout en bas. Envelopper une chaîne dans 31 conteneurs L imbriqués s'écrit sans problème ; un 32e conteneur échoue, et la même frontière s'applique aux M imbriquées :

ValidationException: Nesting Levels have exceeded supported limits:
Attributes in the item have nested levels beyond supported limit

Ensembles (valeurs uniques)

L'ensemble de chaînes (SS), l'ensemble de nombres (NS) et l'ensemble binaire (BS) contiennent des valeurs uniques d'un seul type, sans ordre.
Un ensemble ne peut pas être vide (ça lève une ValidationException).

Utilise un ensemble quand l'appartenance et l'unicité comptent ; utilise une Liste quand l'ordre ou les types mixtes comptent.

Les ensembles réordonnent et rejettent les doublons

Stocke ["zulu", "alpha", "mike"] comme ensemble de chaînes et il se relit ["alpha", "mike", "zulu"]. Un ensemble de nombres se trie numériquement : ["30", "4", "100"] renvoie ["4", "30", "100"]. Les mêmes valeurs dans une Liste reviennent dans l'ordre où tu les as écrites.

Un membre répété est un échec net plutôt qu'une déduplication silencieuse :

ValidationException: Input collection contains duplicates

Et comme un ensemble ne peut jamais être vide, un DELETE de son dernier membre supprime l'attribut. Un code qui s'attend à récupérer un ensemble vide obtient un attribut manquant à la place : teste donc avec attribute_exists plutôt que sur une longueur nulle.

Combien d'éléments tiennent réellement

« Pas de limite au nombre d'éléments » est exact et difficile à exploiter. La réponse utile, c'est 400 Ko divisés par ce que coûte un élément : une liste porte 3 octets de surcharge, puis la taille propre de chaque élément plus 1 octet.

Pour des chaînes UUID de 36 caractères sous une clé de partition d'un caractère, ça tombe à 11 070 éléments. Ajouter un 11 071e est rejeté :

ValidationException: Item size has exceeded the maximum allowed size

Le calculateur de taille d'élément mesure ces deux éléments à 409 599 et 409 636 octets : il trace donc la ligne des 409 600 octets exactement là où le moteur la trace. Écrire le plus gros coûte 400 unités d'écriture.

Aller plus loin

Voir les types de données DynamoDB et convertis des structures imbriquées avec le convertisseur JSON. Télécharge DynoTable pour modifier des attributs de type liste et ensemble.

Références

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

Mesuré et reproduit le 2026-07-28 contre DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 — le nombre d'éléments, la frontière d'imbrication, les allers-retours sur les ensembles et les chaînes d'erreur ci-dessus sont des sorties du moteur, pas des estimations. La formulation des chaînes d'erreur peut différer sur le service en production.