La limite de taille d'item DynamoDB (400 KB)

Un seul item DynamoDB peut contenir au plus 400 KB de données. Quand tu viens de MongoDB (documents de 16 MB) ou d'une ligne relationnelle sans plafond pratique, ce plafond paraît bas — et tu tends à le découvrir à la dure, quand une écriture qui marchait depuis des mois échoue soudain avec une ValidationException parce qu'un item a finalement trop grossi.

La limite n'est pas arbitraire, et ce n'est pas un quota que tu peux relever. C'est une contrainte de modélisation, et les items qui l'atteignent te disent généralement que les données étaient mal modélisées.

Quelle est la taille maximale d'un item dans DynamoDB ?

DynamoDB plafonne un seul item à 400 KB — une limite dure que tu ne peux pas relever. La taille compte les noms d'attributs plus les valeurs ensemble, y compris chaque élément de liste, map et set imbriqués. Les items l'atteignent généralement par croissance non bornée, comme une liste embarquée en expansion perpétuelle ; le correctif est la modélisation, scinder la collection en items séparés, pas la compression.

• 400 KB par item, plafond dur. Non ajustable, pas un quota souple.
• Taille = noms d'attributs + valeurs, ensemble. Les noms d'attributs longs comptent, sur chaque item.
• L'imbrication et les sets comptent aussi. Les listes, maps et leurs valeurs imbriquées s'additionnent toutes.
• La cause habituelle est la croissance non bornée — embarquer une liste qui grossit sans limite sur un item parent.
• Le correctif est la modélisation, pas la compression. Scinde la collection croissante en ses propres items sous une clé de partition partagée.

Le problème : l'item qui grossit pour toujours

Disons que tu suis une flotte de véhicules, et que tu décides de stocker les relevés de télémétrie de chaque véhicule comme une liste sur l'item du véhicule :

PK: VEHICLE#A1   readings: [ {ts, lat, lng, fuel}, {ts, lat, lng, fuel}, ... ]

Pendant un jour ou deux, ça va. Mais les relevés arrivent toutes les quelques secondes et ne s'arrêtent jamais, donc la liste grossit sans borne. Finalement, un relevé de plus pousserait l'item au-delà de 400 KB, et DynamoDB rejette l'écriture avec une ValidationException: Item size has exceeded the maximum allowed size — tu ne peux plus du tout enregistrer de télémétrie pour ce véhicule, parce que chaque mise à jour réécrit l'item entier.

Le bug, ce n'est pas la limite de taille. C'est de modéliser une relation un-à-plusieurs non bornée comme une liste embarquée. Ça ne marche que quand le côté « plusieurs » est borné et petit.

Ce qui compte réellement dans les 400 KB

DynamoDB mesure la taille totale de l'item comme la somme de :

• Chaque nom d'attribut, encodé en UTF-8. Un nom de 20 caractères répété sur des millions d'items est à la fois de la taille et du stockage que tu paies — c'est pourquoi les modélisateurs expérimentés gardent les noms d'attributs courts.
• Chaque valeur d'attribut. Les chaînes et le binaire par leur longueur en octets ; les nombres par un encodage compact ; les booléens et les nulls par un coût fixe minime.
• La structure imbriquée. Une liste ou une map compte sa propre surcharge plus la taille de chaque élément et clé à l'intérieur, jusqu'au bout.

Il n'y a pas de plafond séparé par attribut à prévoir — c'est l'item entier contre la ligne des 400 KB. La documentation AWS sur la taille des items détaille le comptage exact des octets.

Pourquoi la limite existe

Les gros items sont coûteux à déplacer. Les lectures DynamoDB sont mesurées par unités de 4 KB, donc un item de 400 KB coûte 100 RCU en lecture fortement cohérente — et les lectures, écritures et réplications deviennent toutes plus lentes et plus chères à mesure que les items grossissent. Le plafond te pousse vers des items petits et ciblés, et loin de l'anti-pattern « aller chercher un gros blob » vers lequel les débutants NoSQL tendent par habitude relationnelle.

Modéliser pour l'éviter

Pour l'exemple de la flotte, arrête d'embarquer. Donne à chaque relevé son propre item dans la même partition que le véhicule, ordonné par timestamp sur la clé de tri :

PK: VEHICLE#A1   SK: READING#2026-06-27T10:00:05Z   lat, lng, fuel
PK: VEHICLE#A1   SK: READING#2026-06-27T10:00:10Z   lat, lng, fuel

Maintenant aucun item ne grossit, les écritures ne dépassent jamais le plafond, et un seul Query sur VEHICLE#A1 ramène toujours les relevés d'un véhicule comme une seule collection d'items triée. Les sous-listes bornées (une poignée de tags, un bloc de config fixe) peuvent être embarquées ; les non bornées deviennent des items.

Vérifier la taille d'un item dans DynoTable

Avant de t'engager sur une forme, pèse un item représentatif. Dans DynoTable, ouvre-en un en Quick View et il affiche la taille en octets de l'item à côté de ses attributs — pour que tu attrapes une forme trop lourde en parcourant de vraies données, au moment de la conception au lieu de l'écriture échouée.

Tu préfères rester dans le navigateur ? Le calculateur de taille d'item DynamoDB fait la même chose depuis un échantillon collé, en rapportant les KB exacts et les RCU/WCU que chaque lecture et écriture coûtera.

Vérifié par rapport à DynamoDB

Les règles de calcul de taille sont faciles à énoncer et faciles à se tromper subtilement dessus, alors on a confronté les nôtres à la seule autorité qui compte : ce que DynamoDB facture réellement.

L'astuce, c'est que ConsumedCapacity rapporte des unités plutôt que des octets, et qu'une écriture de N octets coûte ceil(N / 1024) WCU. Grossier en général — mais exact sur une frontière. Un item construit pour tomber pile sur 1 024 octets doit coûter 1 WCU, et un item construit pour tomber sur 1 025 doit en coûter 2 : une erreur d'un seul octet dans le calcul fait donc basculer le nombre observé.

Six sur six concordent, et ce sont les paires de frontière qui portent la preuve : les items de 1 024 et 1 025 octets ne diffèrent que d'un seul caractère de remplissage, et DynamoDB les facture différemment — exactement là où notre calcul place la marche.

La conséquence pratique est celle qui coûte de l'argent. Un item qui dépasse le kilo-octet d'un seul octet coûte un WCU entier de plus, et à 4 KB la même falaise réapparaît côté lecture — ramener un item de 1 025 à 1 024 octets divise donc par deux son coût d'écriture, tandis que le faire passer de 1 024 à 1 025 le double. Les noms d'attributs comptent dans le total, et c'est pourquoi raccourcir les clés d'une table sollicitée n'est pas de la micro-optimisation.

Pièges + étapes suivantes

• Surveille les listes embarquées qui grossissent avec le trafic — ce sont la bombe à retardement classique des 400 KB. Borne-les ou scinde-les.
• Raccourcis les noms d'attributs sur les items à cardinalité élevée — c'est de la taille et du stockage récupérés gratuitement.
• Les grosses valeurs appartiennent à S3. Stocke les gros blobs (images, documents) dans S3 et ne garde que la clé sur l'item.
• Connexe : dénormalisation et relations un-à-plusieurs couvrent quand embarquer vs scinder.

Tu veux voir les vraies tailles d'items d'une table d'un coup d'œil ? Télécharge DynoTable et inspecte tes données directement.

Chiffres de capacité vérifiés le 2026-07-26 par rapport au service DynamoDB réel dans us-east-1 (pnpm content:verify-item-size).