¿Puede DynamoDB almacenar blobs?

Sí, dentro de unos límites. DynamoDB guarda objetos binarios grandes (BLOB) en atributos Binary (B), codificados en base64 en la red, siempre que el Item entero se mantenga por debajo de 400 KB. Para cualquier cosa mayor — vídeo, audio, imágenes de alta resolución — AWS recomienda guardar el blob en Amazon S3 y dejar en DynamoDB solo una referencia y los metadatos.

Guardar un blob directamente

Mete los bytes en un atributo Binary. Las aplicaciones codifican los valores binarios en base64 antes de enviarlos; DynamoDB cuenta la longitud en bytes en bruto para el límite de 400 KB por Item. Los blobs pequeños (firmas, cargas compactas) caben de sobra.

Cuántos bytes caben en realidad

Los 400 KB son del Item, no del blob. Buscar el límite por bisección da un techo exacto: un Item que no contiene más que una clave de partición de un carácter y un atributo Binary admite 409.594 bytes de blob. Un byte más y la escritura falla:

ValidationException: Item size has exceeded the maximum allowed size

Seis atributos de metadatos realistas junto a él (tipo de contenido, dimensiones, quién lo subió, marca de tiempo) cuestan 94 bytes y bajan el techo a 409.500.

La codificación base64 es un detalle de la red y nada más. Ese put de 409.594 bytes envía 546.128 bytes de base64 en el cuerpo de la petición y DynamoDB lo acepta, así que la idea tan repetida de que base64 se come un tercio de tu presupuesto es falsa. Lo que sí cuesta es rendimiento: un blob a tamaño completo son 400 unidades de escritura por put y 100 unidades de lectura por lectura fuertemente consistente, frente a 1 y 0,5 para un Item pequeño.

El patrón de objeto grande

Cuando un blob supera los 400 KB:

Guarda el objeto en Amazon S3.
Deja en DynamoDB la clave de S3 más los metadatos (nombre, tamaño, propietario, marcas de tiempo).

Esto empareja las búsquedas indexadas rápidas de DynamoDB con el almacenamiento de objetos barato e ilimitado de S3. Para datos solo ligeramente por encima del límite, AWS también sugiere comprimir los atributos grandes (salida GZIP o LZO guardada en un atributo Binary) o repartirlos entre varios Items.

La compresión rescata el texto, no el contenido multimedia

Ese consejo de compresión funciona exactamente con un tipo de blob. gzip -9 sobre un fichero de bloqueo YAML de 614.499 bytes devuelve 164.302 bytes, un recorte del 73% que lo lleva de imposible a cómodo. El mismo comando sobre un PNG de 794.311 bytes devuelve 785.175 bytes, un ahorro del 1,2%, porque el formato ya se comprimió a sí mismo. Así que la compresión te da margen para logs, cargas JSON y texto, y no te da nada para los ficheros multimedia que son el motivo habitual de chocar con el límite.

Una advertencia

No hay transacciones entre servicios entre DynamoDB y S3, así que tu aplicación tiene que gestionar por sí misma los fallos parciales y los objetos huérfanos.

Profundiza

Comprueba tamaños con la calculadora de tamaño de Item y lee la guía del límite de tamaño de Item. Descarga DynoTable para ver datos binarios.

Referencias

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.

Medido el 2026-07-28 contra DynamoDB Local 3.3.0 mediante @aws-sdk/client-dynamodb 3.1095.0 — ambos techos de bytes se encontraron por bisección, no se dedujeron, y las cifras de gzip vienen de ejecutar gzip -9 sobre los dos ficheros descritos. El motor de producción de AWS puede redactar sus rechazos de otra forma.