DynamoDB のアイテムサイズ上限（400 KB）

単一の DynamoDB アイテムが保持できるデータは、最大 400 KB です。MongoDB（16 MB の ドキュメント）や、実用上の上限がないリレーショナルの行から来ると、その上限は低く感じます — そして、たいていは痛い目に遭って発見します。何か月も動いていた書き込みが、あるとき1つの アイテムがついに大きくなりすぎて ValidationException で突然失敗するのです。

この上限は恣意的ではなく、引き上げられるクォータでもありません。これはモデリングの制約で あり、それに当たるアイテムはたいてい、データのモデル化が間違っていたことを告げています。

DynamoDB の最大アイテムサイズは？

DynamoDB は単一のアイテムを 400 KB に制限します — 引き上げられないハードな上限です。 サイズは属性名と値を合わせて数え、ネストしたすべてのリスト、マップ、セットの要素を含みます。 アイテムがこれに当たるのは、たいてい際限のない肥大化を通じて — 際限なく膨らむ埋め込み リストのように — です。対処はモデリングであり、コレクションを別々のアイテムに分割すること であって、圧縮ではありません。

• アイテムあたり 400 KB、ハードな上限。 調整不可、ソフトクォータでもありません。
• サイズ ＝ 属性名 ＋ 値、合わせて。 長い属性名は、すべてのアイテムでカウントされます。
• ネストとセットもカウントされます。 リスト、マップ、そのネストした値がすべて 積み上がります。
• よくある原因は際限のない肥大化 — 親アイテムに、限りなく増えるリストを埋め込むこと です。
• 対処はモデリングであって、圧縮ではありません。 増え続けるコレクションを、共有した パーティションキーの下の独立したアイテムに分割します。

問題: 永遠に増え続けるアイテム

車両群を追跡していて、各車両のテレメトリ測定値を車両アイテム上のリストとして格納すると 決めたとします。

PK: VEHICLE#A1   readings: [ {ts, lat, lng, fuel}, {ts, lat, lng, fuel}, ... ]

1日か2日は問題ありません。しかし測定値は数秒ごとに届いて止まらないので、リストは際限なく 増えます。やがて、あと1つの測定値でアイテムが 400 KB を超えることになり、DynamoDB は ValidationException: Item size has exceeded the maximum allowed size で書き込みを拒否します — 各更新がアイテム全体を書き直すため、その 車両のテレメトリをもはや一切記録できなくなります。

バグはサイズ上限ではありません。際限のない 一対多の関係を埋め込みリストとしてモデル化 したことです。それがうまくいくのは、「多」の側が有界で小さい場合だけです。

実際に 400 KB に何がカウントされるか

DynamoDB はアイテムの合計サイズを、次の合計として測ります。

• すべての属性名、UTF-8 エンコード。数百万のアイテムにわたって繰り返される20文字の名前は、 サイズでもあり、支払うことになるストレージでもあります — 経験豊富なモデラーが属性名を 短く保つのはこのためです。
• すべての属性値。 文字列とバイナリはそのバイト長で、数値はコンパクトなエンコードで、 ブール値と null はごくわずかな固定コストで。
• ネスト構造。 リストやマップは自身のオーバーヘッドに 加えて、その中のすべての 要素とキーのサイズを、末端まですべてカウントします。

回避策を考えるべき属性ごとの個別の上限はありません — アイテム全体 が 400 KB のラインに 対して測られます。AWS のアイテムサイズのドキュメント が正確なバイト計算を詳述しています。

なぜこの上限が存在するのか

大きなアイテムは移動にコストがかかります。DynamoDB の読み取りは 4 KB 単位で計測されるので、 400 KB のアイテムを強整合で読むには 100 RCU かかります — そしてアイテムが大きくなるほど、 読み取り、書き込み、複製のすべてが遅く高価になります。この上限は あなたを 小さく的を絞ったアイテムへ押しやり、リレーショナルの習慣から NoSQL 初心者が手を伸ばしがちな 「1つの巨大な塊を取得する」アンチパターンから遠ざけます。

回避するモデリング

車両群の例では、埋め込みをやめましょう。各測定値に、車両と同じパーティション内で、 ソートキーのタイムスタンプで順序付けた 独自のアイテム を与えます。

PK: VEHICLE#A1   SK: READING#2026-06-27T10:00:05Z   lat, lng, fuel
PK: VEHICLE#A1   SK: READING#2026-06-27T10:00:10Z   lat, lng, fuel

これで単一のアイテムが成長することはなくなり、書き込みが上限を超えることも決してなく、 VEHICLE#A1 に対する単一の Query が、依然として車両の測定値を1つのソート済み アイテムコレクション として返します。有界なサブリスト （ひとつまみのタグ、固定の設定ブロック）は埋め込んで構いません。際限のないものはアイテムに します。

DynoTable でアイテムサイズを確認する

形を確定させる前に、代表的なアイテムを量りましょう。DynoTable では、Quick View で 1つ開くと、アイテムのバイトサイズが属性と並んで表示されます — なので、失敗する書き込みで ではなく設計時に、実データを閲覧しながら重すぎる形を捕まえられます。

ブラウザで済ませたいですか？ DynamoDB アイテムサイズ計算ツール が、貼り付けた サンプルから同じことを行い、正確な KB と、各読み取り・書き込みにかかる RCU/WCU を報告します。

DynamoDB に照らして検証済み

サイズ計算のルールは、言うのは簡単でも微妙に間違えやすいものです。そこで私たちは、唯一意味の ある権威 — DynamoDB が実際に課金する内容 — に照らして自分たちの計算を確認しました。

コツは、ConsumedCapacity がバイトではなくユニットを報告し、N バイトの書き込みが ceil(N / 1024) WCU かかるという点にあります。一般には粗いのですが、境界上では正確です。 ちょうど 1024 バイトに着地するよう組み立てたアイテムは必ず 1 WCU、1025 バイトに着地する ものは必ず 2 WCU になるので、計算に1バイトの誤りがあれば観測される数値がひっくり返ります。

6件中6件が一致し、証明を担っているのは境界のペアです。1,024 バイトと 1,025 バイトの アイテムはパディング1文字分しか違わないのに、DynamoDB はそれらを異なる料金で課金します — まさに私たちの計算が段差の位置だと言っているところで。

実務上の帰結は、お金がかかる方のものです。1キロバイトを1バイト超えたアイテムは、まるまる 1 WCU 余計にかかります。そして 4 KB では同じ崖が読み取り側に現れます — なのでアイテムを 1,025 バイトから 1,024 バイトに削れば書き込みコストは半分になり、1,024 から 1,025 に 膨らませれば倍になります。属性名も合計にカウントされるので、ホットなテーブルでキー名を 短くするのはマイクロ最適化ではありません。

落とし穴と次のステップ

• トラフィックとともに増える埋め込みリストに注意 — それらは典型的な 400 KB の 時限爆弾です。有界にするか、切り出しましょう。
• 属性名を短くする — カーディナリティの高いアイテムでは、無料でサイズとストレージが 取り戻せます。
• 大きな値は S3 へ。 大きな塊（画像、ドキュメント）は S3 に格納し、アイテムには キーだけを保持しましょう。
• 関連: 非正規化 と 一対多の関係 が、いつ埋め込み、いつ分割 するかを扱います。

テーブル全体の実際のアイテムサイズをひと目で見たいですか？ DynoTable をダウンロード して、データを直接調べましょう。

キャパシティの数値は 2026-07-26 に us-east-1 の実稼働 DynamoDB サービスに照らして検証しました（pnpm content:verify-item-size）。