Combien de données DynamoDB peut-il stocker ?

Effectivement sans limite. Une table DynamoDB n'a pas de taille maximale et monte en charge horizontalement, quel que soit le nombre d'éléments et d'octets. Les vraies limites sont par élément (400 Ko) et, uniquement sur les tables dotées d'un index secondaire local, 10 Go par collection d'éléments (une valeur de clé de partition). Les tables sans LSI n'ont aucun plafond de taille de partition.

Taille de table : aucun plafond

DynamoDB répartit automatiquement les données sur de nombreuses partitions physiques à mesure qu'elles grossissent. Il n'y a aucune taille de table maximale configurée — capacité et stockage montent en charge au fil de tes écritures.

Les limites qui existent bel et bien

400 Ko — taille maximale d'un seul élément, mesurée en unités binaires et comptant les noms d'attribut autant que les valeurs (où tombe exactement cette frontière).
10 Go — taille maximale d'une collection d'éléments (tous les éléments partageant une valeur de clé de partition) uniquement quand la table possède un index secondaire local (LSI). Sans LSI, ce plafond ne s'applique pas.

La taille que tu peux mesurer n'est pas celle que tu paies

La façon évidente de répondre à « combien est-ce que je stocke ? », c'est DescribeTable, qui renvoie TableSizeBytes. Ce nombre est plus petit que ta facture, et c'est voulu. D'après les recommandations de facturation d'AWS : "DynamoDB measures the size of your billable data by adding the raw byte size of your data plus a per-item storage overhead that depends on the features you have enabled", et "Storage usage values in the CUR will be higher compared with the storage values when using DescribeTable, because DescribeTable does not include the per-item storage overhead."

C'est bien ce que le moteur rapporte. Une table contenant 40 éléments d'environ 3 Ko chacun est revenue à TableSizeBytes: 120700, c'est-à-dire le contenu brut et rien d'autre. La surcharge est invisible depuis l'API et n'apparaît que dans le Cost and Usage Report.

L'écart entre les deux grandit donc avec le nombre d'éléments, pas avec leur taille. Dix millions de tout petits éléments paient cette surcharge dix millions de fois ; les mêmes octets tassés dans cent mille éléments plus gros la paient cent mille fois. Si ta facture dépasse ce que suggère TableSizeBytes, une table large de petites lignes en est la raison habituelle.

Ce que coûte l'« absence de plafond »

Le stockage est la partie indulgente. Une table de 1 To dans us-east-1, ce sont 1 024 Go à 0,25 $ par Go-mois : 256 $ par mois, ou 249,75 $ une fois l'allocation gratuite de 25 Go appliquée.

La taille des éléments est la partie impitoyable, parce que les écritures s'arrondissent au Ko. Le même million d'éléments coûte des montants radicalement différents à écrire, à 0,625 $ par million d'unités de requête d'écriture à la demande :

Taille d'élément	Unités d'écriture chacun	1 M d'écritures (us-east-1, à la demande)
1 Ko	1	0,63 $
100 Ko	100	62,50 $
400 Ko	400	250,00 $

La grandeur autour de laquelle tu conçois n'est donc pas la taille de la table mais celle de l'élément. Pousse les gros blobs vers S3 en gardant le pointeur dans DynamoDB, et évite les collections d'éléments sans borne sous une clé chaude. Vérifie tes propres chiffres dans le calculateur de tarifs.

Aller plus loin

Lis les collections d'éléments DynamoDB et comment fonctionnent les clés de partition DynamoDB. Télécharge DynoTable pour explorer efficacement de grosses tables.

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus ; quotas et prix revérifiés le 2026-07-28.

Le chiffre TableSizeBytes a été mesuré le 2026-07-28 sur DynamoDB Local 3.3.0 (amazon/dynamodb-local:latest) via @aws-sdk/client-dynamodb 3.1095.0. DynamoDB Local n'est pas le service, et aucune constante de surcharge par élément n'en est déduite.