DynamoDB 能存储 blob 吗？

能，但有限制。DynamoDB 把二进制大对象（BLOB）存在 Binary（B）属性里，在网络上以 base64 编码传输，前提是整个项保持在 400 KB 以内。更大的东西——视频、音频、高分辨率图片——AWS 建议把 blob 存进 Amazon S3，DynamoDB 里只留一个引用和元数据。

直接存一个 blob

把字节放进一个 Binary 属性。应用在发送前会把二进制值做 base64 编码；DynamoDB 计入 400 KB 项大小的是原始字节长度。小 blob（签名、紧凑的载荷）装得很轻松。

到底能装下多少字节

400 KB 说的是项，不是 blob。对边界做二分查找能给出一个确切的天花板：一个除了单字符分区键和一个 Binary 属性之外什么都没有的项，能装下 409,594 字节的 blob。再多一个字节，写入就失败：

ValidationException: Item size has exceeded the maximum allowed size

在它旁边放六个现实的元数据属性（内容类型、尺寸、上传者、时间戳）会花掉 94 字节，把天花板压到 409,500。

base64 编码只是一个传输细节，仅此而已。那次 409,594 字节的写入在请求体里发出了 546,128 字节的 base64，DynamoDB 照样接受，所以"base64 会吃掉你三分之一预算"这个流传甚广的说法是错的。它真正花掉的是吞吐量：一个满尺寸的 blob 每次写入是 400 个写单元，每次强一致读是 100 个读单元，而一个小项分别只要 1 和 0.5。

大对象模式

当一个 blob 超过 400 KB 时：

把对象存进 Amazon S3。
在 DynamoDB 里保留 S3 键加元数据（名称、大小、所有者、时间戳）。

这把 DynamoDB 的快速索引查找和 S3 廉价、无上限的对象存储配在了一起。对于只是略微超限的数据，AWS 还建议压缩大属性（把 GZIP 或 LZO 的输出存进一个 Binary 属性），或者把它们拆到多个项上。

压缩救得了文本，救不了媒体文件

那条压缩建议只对一类 blob 有效。对一个 614,499 字节的 YAML 锁文件跑 gzip -9 得到 164,302 字节，砍掉 73%，直接把它从不可能变成绰绰有余。同样的命令对一个 794,311 字节的 PNG 跑出来是 785,175 字节，只省了 1.2%，因为这个格式早就自己压过了。所以压缩给你换来的是日志、JSON 载荷和文本的空间，而对那些通常正是撞上限制的媒体文件，一点用都没有。

一点告诫

DynamoDB 和 S3 之间没有跨服务事务，所以部分失败和孤儿对象只能由你的应用自己处理。

深入了解

用项大小计算器检查大小，并阅读项大小限制指南。下载 DynoTable 来查看二进制数据。

参考资料

最后核实于 2026-07-13，依据上方链接的 AWS 官方文档。

2026-07-28 针对 DynamoDB Local 3.3.0、通过 @aws-sdk/client-dynamodb 3.1095.0 测量——两个字节天花板都是二分查找出来的，不是推算的；gzip 数字来自对上述两个文件运行 gzip -9。AWS 的生产引擎给出的拒绝措辞可能不同。