DynamoDB のコストモデル: なぜ SQL は請求を見えなくするのか
DynamoDB に対して本物の SQL を実行できるのは強力です — ネイティブにはそのどれも
提供しないデータベースの上で、JOIN、GROUP BY、任意の WHERE 句が手に入ります。しかし
SQL は、クエリプランナーとすべての列に対するセカンダリインデックスを備えたエンジンの
ために設計されており、DynamoDB はそのどちらも持ちません。まったく正当な SELECT が、
テーブル内のすべてのアイテムを読み取り — そして課金する — フルテーブル Scan に
コンパイルされることがあります。
これが SQL という抽象化の諸刃の剣です。高コストなアクセスパターンを無料に見せてしまう のです。このガイドではその下にあるコストモデルを解説し、この利便性が予期せぬ請求に 変わらないようにします。そして DynoTable がクエリを実行する前にコストを可視化する 方法を示します。
DynamoDB 上の SQL は、なぜ見た目より高くつくのか?
リレーショナルデータベースは WHERE status = 'active' を効率的に処理できます。指定した
任意の列に対してインデックスを構築するからです。DynamoDB はそうしません。効率的に
処理できるのはただ1つ、パーティションキーだけです (オプションでソートキーや
グローバルセカンダリインデックスによって絞り込めます)。それ以外はすべて Scan です。
- パーティションキーの等価条件は Query です。 DynamoDB はそのキー配下のアイテムに 直接ジャンプし、それらだけを読み取ります。範囲が限られていて安価です。
- それ以外はすべて Scan + Filter です。 DynamoDB はテーブル内のすべてのアイテムを
読み取り、その後で
WHEREをFilterExpressionとして適用します — 読み取りの 後にです。課金されるのは Scan したすべての分であって、返ってきたわずかな行の分では ありません。
この最後の点が罠です。WHERE 句は作業量を絞り込むように見えます。しかしキー以外の
属性では、絞り込むのは出力だけで — 読み取りコストはすでに費やされています。
Query vs Scan: RCU の計算
DynamoDB は読み取りを読み取りキャパシティユニット (RCU) で課金します:
- 1 RCU = 最大 4 KB までのアイテム1件の強力な整合性のある読み取り1回。結果整合性の ある読み取りはその半分のユニットで済みます。読み取りは 4 KB ごとに切り上げられます。
- Query は1つのパーティションキー配下のアイテムだけを読み取ります — コストはテーブル ではなく、一致したアイテムに比例します。
- Scan はテーブル全体を 4 KB ずつ読み取ります。1 GB のテーブルは、1回のフルパスで およそ 262,000 結果整合性のある RCU になります — パスのたびに、毎回です。
FilterExpression はその数値を減らしません。フィルタリングは読み取りの後に行われる
ので、フィルターありの Scan はフィルターなしの場合とまったく同じコストがかかります。
自分のデータでの実際の数値は、アイテムサイズ計算ツール
と料金計算ツールで算出してください。
どの SQL 構文がひそかに Scan に変わるのか?
- パーティションキーの等価条件がない
WHERE→ 読み取り後にフィルターをかけるフル Scan。 JOIN→ DynamoDB にサーバーサイドの結合はありません。結合される各テーブルは個別に 取得され、クライアントサイドでつなぎ合わされます — N+1 のアクセスパターンで、 結合される行ごとに1リクエストです。COUNT、SUM、GROUP BY、集計 → サーバーサイドの集計は存在しないので、一致した すべてのアイテムが読み取られます。Scan の上では、それはテーブル全体を読み取ることを 意味します。- キー以外の属性に対する
ORDER BYやDISTINCT→ 並べ替えと重複排除は、Scan された 対象に対してクライアントサイドで行われます。
これらのどれも実行して間違いというわけではありません — Scan がまさに望むもので あることもあります。肝心なのは、自分がいつ Scan を実行しているのかを知ることです。
SQL にコストについて正直でいてもらうには?
- アクセスパターンを中心にキーを設計しましょう。 最も安価なクエリは、キースキーマが すでに答えられるものです。シングルテーブル設計ツール と Query vs Scan ガイドで計画しましょう。
WHEREにパーティションキーの等価条件を入れて、Scan の代わりに Query にしましょう。- GSI を追加して、Scan してフィルターする代わりに2つ目のアクセスパターンに対応 しましょう。
- 実行する前にコストを読みましょう。 DynoTable の Workbench は SQL を実際の DynamoDB
オペレーションにコンパイルし、プランを表示します — Scan か Query か、どのインデックスを
使うか、キー条件と Scan 後のフィルターの違い、そして見積もりの RCU コスト — そしてフル
Scan と N+1 の結合をインラインで指摘します。これは DynamoDB が決して出荷しなかった
EXPLAINです。Scan はなぜ遅く高コストなのかと オンデマンド vs プロビジョンドキャパシティも 参照してください。
DynoTable の SQL はコスト問題を悪化させるのか?
いいえ — むしろコストを可視化するからです。DynamoDB 上の SQL への批判はもっともです。 Scan を隠す抽象化は、自分の足を撃つことを許してしまいます。DynoTable の答えは、SQL を 取り除くことではなく、その背後にコストの X 線を置くことです。Workbench のすべてのクエリは、 実行される前に本当の DynamoDB の姿をプレビューします。だから SQL の使い心地と、 ネイティブモデルが与えてくれる RCU やキー設計についての正直さの両方を保てます。
これに AI エージェントは必要か?
いいえ — テーブルビューアー、SQL Workbench、コストプレビューはすべて、それなしで完全に 機能します。AI エージェントは DynoTable の目玉機能の1つで — スキーマを理解したクエリを 書き、データを変換し、さらに多くのことを行う DynamoDB ネイティブのコーディングエージェント です — 使いたいときにいつでもそこにあります。自分自身の AWS Bedrock 上で動作するので、 AWS に直接、原価で支払い (割増しなし)、データがアカウントから出ることは決してありません。 役立つときにオンにしてください。どちらにしてもコアのクライアントは完結しています。
自分の作業は移行できるか?
はい。DynoTable は囲い込みではなく標準を話します。標準の SQL、標準の AWS 認証情報と SSO、 CSV/JSON エクスポート、TypeScript・JSON-Schema・Zod への推論スキーマエクスポート、そして 自分のツールやエージェントが接続できる MCP サーバー。クエリ、設定、スキーマはきれいに エクスポートでき — 何もロックインされません。
試してみる
DynoTable をダウンロードして、自分のテーブルに対して SQL Workbench を開いて みてください — コストプレビューが、実行する前にすべてのクエリが本当にいくらかかるかを 示してくれます。