Can DynamoDB store blobs?

Yes, within limits. DynamoDB stores binary large objects (BLOBs) in Binary (B) attributes, base64-encoded on the wire, as long as the entire item stays under 400 KB. For anything larger — video, audio, high-resolution images — AWS recommends storing the blob in Amazon S3 and keeping only a reference and metadata in DynamoDB.

Storing a blob directly

Put the bytes in a Binary attribute. Applications base64-encode binary values before sending them; DynamoDB counts the raw byte length toward the 400 KB item size. Small blobs (signatures, compact payloads) fit comfortably.

How many bytes actually fit

400 KB is the item, not the blob. Binary-searching the boundary gives an exact ceiling: an item holding nothing but a one-character partition key and one Binary attribute takes 409,594 bytes of blob. One more byte and the write fails:

ValidationException: Item size has exceeded the maximum allowed size

Six realistic metadata attributes alongside it (content type, dimensions, uploader, timestamp) cost 94 bytes and drop the ceiling to 409,500.

The base64 encoding is a wire detail and nothing more. That 409,594-byte put sends 546,128 bytes of base64 in the request body and DynamoDB accepts it, so the widely repeated idea that base64 eats a third of your budget is wrong. What it does cost is throughput: a full-size blob is 400 write units per put and 100 read units per strongly consistent read, against 1 and 0.5 for a small item.

The large-object pattern

When a blob exceeds 400 KB:

Store the object in Amazon S3.
Keep the S3 key plus metadata (name, size, owner, timestamps) in DynamoDB.

This pairs DynamoDB's fast indexed lookups with S3's cheap, unbounded object storage. For data only modestly over the limit, AWS also suggests compressing large attributes (GZIP or LZO output stored in a Binary attribute) or splitting them across multiple items.

Compression rescues text, not media

That compression advice works on exactly one kind of blob. gzip -9 over a 614,499-byte YAML lockfile returns 164,302 bytes, a 73% cut that takes it from impossible to comfortable. The same command over a 794,311-byte PNG returns 785,175 bytes, a saving of 1.2%, because the format compressed itself already. So compression buys you room for logs, JSON payloads and text, and buys you nothing for the media files that are the usual reason to hit the limit.

A caveat

There are no cross-service transactions between DynamoDB and S3, so your application must handle partial failures and orphaned objects itself.

Go deeper

Check sizes with the item size calculator and read the item size limit guide. Download DynoTable to view binary data.

References

Last verified 2026-07-13 against the official AWS documentation linked above.

Measured 2026-07-28 against DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 — both byte ceilings were found by binary search rather than derived, and the gzip figures come from running gzip -9 on the two files described. AWS's production engine may phrase its rejections differently.