DynamoDB 能儲存二進位大型物件嗎？

可以，但有限制。DynamoDB 以 Binary（B）屬性儲存二進位大型物件（BLOB），在線路上以 base64 編碼，只要整個項目維持在 400 KB 以下即可。更大的東西 — 影片、音訊、高解析度影像 — AWS 建議把物件存進 Amazon S3，DynamoDB 裡只留一個參考與中繼資料。

直接儲存一個 BLOB

把位元組放進一個 Binary 屬性。應用程式在送出前會把二進位值做 base64 編碼；DynamoDB 計入 400 KB 項目大小的是原始位元組長度。小型 BLOB（簽名、精簡的 payload）放得很寬裕。

實際上塞得下多少位元組

400 KB 是項目，不是 BLOB。用二分搜尋去逼近那條界線，會得到一個確切的上限：一個只裝了單字元 partition key 與一個 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 key 加上中繼資料（名稱、大小、擁有者、時間戳記）。

這讓 DynamoDB 快速的索引查找與 S3 便宜、無上限的物件儲存搭在一起。對於只稍微超過上限的資料，AWS 也建議壓縮大型屬性（把 GZIP 或 LZO 的輸出存進 Binary 屬性），或把它拆到多個項目中。

壓縮救得了文字，救不了媒體

那個壓縮建議恰好只對一種 BLOB 有效。對一個 614,499 位元組的 YAML lockfile 執行 gzip -9 會得到 164,302 個位元組，砍掉 73%，讓它從不可能變成綽綽有餘。同一個指令對一個 794,311 位元組的 PNG 只得到 785,175 個位元組，省下 1.2%，因為那個格式早就自己壓過了。所以壓縮替你買到的是日誌、JSON payload 與文字的空間，對那些讓你撞上限的媒體檔案則什麼都買不到。

一個附帶說明

DynamoDB 與 S3 之間沒有跨服務交易，所以你的應用程式必須自行處理部分失敗與孤兒物件。

深入了解

用項目大小計算機檢查大小，並閱讀項目大小上限指南。下載 DynoTable 即可檢視二進位資料。

參考資料

最後驗證於 2026-07-13，對照上方連結的官方 AWS 文件。

已於 2026-07-28 透過 @aws-sdk/client-dynamodb 3.1095.0，對照 DynamoDB Local 3.3.0 量測 — 兩個位元組上限都是用二分搜尋找出來的，不是推導出來的，而 gzip 數字來自對文中描述的那兩個檔案執行 gzip -9。AWS 的正式引擎在措辭上可能與此不同。