DynamoDB peut-il stocker des blobs ?

Oui, dans certaines limites. DynamoDB stocke les objets binaires volumineux (BLOB) dans des attributs Binaires (B), encodés en base64 sur le réseau, tant que l'élément entier reste sous 400 Ko. Au-delà — vidéo, audio, images haute résolution — AWS recommande de stocker le blob dans Amazon S3 et de ne garder qu'une référence et des métadonnées dans DynamoDB.

Stocker un blob directement

Mets les octets dans un attribut Binaire. Les applications encodent les valeurs binaires en base64 avant l'envoi ; DynamoDB compte la longueur en octets bruts dans la taille de l'élément de 400 Ko. Les petits blobs (signatures, charges utiles compactes) y tiennent confortablement.

Combien d'octets tiennent réellement

400 Ko, c'est l'élément, pas le blob. Dichotomiser la frontière donne un plafond exact : un élément ne contenant qu'une clé de partition d'un caractère et un attribut Binaire accepte 409 594 octets de blob. Un octet de plus et l'écriture échoue :

ValidationException: Item size has exceeded the maximum allowed size

Six attributs de métadonnées réalistes à côté (type de contenu, dimensions, auteur du dépôt, horodatage) coûtent 94 octets et font tomber le plafond à 409 500.

L'encodage base64 est un détail de transport, rien de plus. Ce put de 409 594 octets envoie 546 128 octets de base64 dans le corps de la requête et DynamoDB l'accepte : l'idée largement répandue selon laquelle le base64 mange un tiers de ton budget est donc fausse. Ce qu'il coûte, en revanche, c'est du débit : un blob à pleine taille, c'est 400 unités d'écriture par put et 100 unités de lecture par lecture fortement cohérente, contre 1 et 0,5 pour un petit élément.

Le motif des gros objets

Quand un blob dépasse 400 Ko :

Stocke l'objet dans Amazon S3.
Garde la clé S3 plus les métadonnées (nom, taille, propriétaire, horodatages) dans DynamoDB.

Ça associe les recherches indexées rapides de DynamoDB au stockage d'objets bon marché et illimité de S3. Pour des données à peine au-dessus de la limite, AWS suggère aussi de compresser les gros attributs (sortie GZIP ou LZO stockée dans un attribut Binaire) ou de les découper sur plusieurs éléments.

La compression sauve le texte, pas les médias

Ce conseil de compression ne marche que sur un seul type de blob. gzip -9 sur un fichier de verrouillage YAML de 614 499 octets rend 164 302 octets, une réduction de 73 % qui le fait passer d'impossible à confortable. La même commande sur un PNG de 794 311 octets rend 785 175 octets, une économie de 1,2 %, parce que le format s'est déjà compressé lui-même. La compression t'achète donc de la place pour des logs, des charges utiles JSON et du texte, et ne t'achète rien pour les fichiers médias qui sont la raison habituelle d'atteindre la limite.

Une réserve

Il n'existe pas de transactions inter-services entre DynamoDB et S3 : ton application doit donc gérer elle-même les échecs partiels et les objets orphelins.

Aller plus loin

Contrôle les tailles avec le calculateur de taille d'élément et lis le guide limite de taille des éléments. Télécharge DynoTable pour visualiser des données binaires.

Références

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

Mesuré le 2026-07-28 sur DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 — les deux plafonds en octets ont été trouvés par recherche dichotomique et non déduits, et les chiffres gzip viennent de l'exécution de gzip -9 sur les deux fichiers décrits. Le moteur de production d'AWS peut formuler ses refus différemment.