「とりあえずDynamoDBで」——この一言が、半年後の技術的負債になることがあります。逆に「DBは慣れたPostgreSQLで」が、スケール時に詰む設計になることもあります。
データ層の選定は、システムの寿命を最も強く規定する一度きりの判断です。アプリケーションコードは書き直せますが、データモデルとDBエンジンは後から差し替えるコストが桁違いに高い。だからこそ、ここは流行や好みではなく、要件から導いた軸で決めるべきです。
本記事は、発注前・着手前の「NoSQL（DynamoDB） vs RDB（Amazon RDS / Aurora PostgreSQL）」という意思決定に、再利用できるフレームワークで答えます。私自身、サーバーレスマルチテナント決済プラットフォームの信頼性レイヤー（Lambda + DynamoDB、本番稼働中の二重課金0件を維持）を設計・主導してきた立場から、「どこをDynamoDBに寄せ、どこをRDBに残すか」を実戦の線引きとして書きます。
結論を先に言います。DynamoDBとRDBは競合ではなく、得意分野が違う道具です。そして多くの実システムでは、**二者択一ではなく使い分け（ハイブリッド）**が正解になります。
仕様・上限値はすべてAWS公式ドキュメント（2026年6月時点）に照合しています。料金はリージョン・時期で変わるため、最終金額は必ず公式料金ページで確認してください。
1. 結論：選定は「4つの軸」で決める
DynamoDBかRDBかを「速いから」「安いから」「サーバーレスだから」で決めると、ほぼ外します。判断すべきは次の4軸です。
| 軸 | 問い | DynamoDB有利 | RDB(Aurora/PostgreSQL)有利 |
|---|---|---|---|
| アクセスパターンの確定度 | クエリの形を着手前に列挙できるか？ | 事前に確定できる | 後から自由に増える／探索的 |
| スケール | 想定する読み書きの規模・成長は？ | 超大規模・青天井の成長 | 中〜大規模で十分 |
| クエリ自由度と整合性 | JOIN・集計・アドホック検索が要るか？ | キー/インデックス引きで足りる | JOIN・GROUP BY・分析が中心 |
| 運用負荷 | 運用にどれだけ人手をかけられるか？ | 運用レスを最優先 | チューニング余地を持ちたい |
この4軸は独立ではなく、しばしば連動します。たとえば「アクセスパターンを事前確定でき、超大規模で、キー引きで足り、運用レスにしたい」が揃えばDynamoDBの独擅場。逆に「クエリが後から自由に増え、JOINと集計が中心」ならRDB一択です。
そしてAWS公式は、両者の最適ワークロードを明確に区別しています。
RDBMSの最適ワークロード: アドホッククエリ、データウェアハウス、OLAP（オンライン分析処理）。 DynamoDBの最適ワークロード: ソーシャルネットワーク、ゲーム、メディア共有、IoTを含むWebスケールアプリケーション。
ここがすべての出発点です。アドホックに問い合わせて分析したいならRDB、決まった問いに超大規模・低レイテンシで答え続けたいならDynamoDB。これを軸足に、以下で各論を詰めます。
2. DynamoDBとは何か（公式定義を正確に）
判断の前に、DynamoDBの正体を公式定義で押さえます。マーケティングの「速いKVS」ではなく、設計上の制約と引き換えに無制限スケールを得たエンジンです。
公式の一文がすべてを要約しています。
Amazon DynamoDB is a serverless, fully managed, distributed NoSQL database with single-digit millisecond performance at any scale.（DynamoDBは、サーバーレスで、フルマネージドな、分散NoSQLデータベースであり、あらゆるスケールで一桁ミリ秒の性能を提供する）
ここから読み取るべき性質:
- サーバーレス: サーバーのプロビジョニング・パッチ・管理・運用が不要。バージョンもメンテナンスウィンドウもない。オンデマンドモードはトラフィックが無ければゼロまでスケールし、コールドスタートもない。
- フルマネージド: セットアップ・高可用性・ハードウェア・セキュリティ・バックアップ・監視をAWSが引き受ける。作った瞬間から本番ワークロードに使える。
- NoSQL（キーバリュー＋ドキュメント）: キーバリューとドキュメントの両モデルをサポート。スキーマレスで、主キー以外は各アイテムが固有の属性を持てる。
- JOINが無い: 公式は明言します。「Unlike relational databases, DynamoDB doesn't support a JOIN operator.（リレーショナルDBと違い、DynamoDBはJOIN演算子をサポートしない）」。代わりにデータの非正規化を推奨します。
- 一桁ミリ秒 × 任意スケール: 100ユーザーでも1億ユーザーでも一貫した一桁ミリ秒。スケールのために非効率な機能（JOINなど）を意図的に省いています。
つまりDynamoDBは「JOINや柔軟なアドホッククエリを捨てる代わりに、予測可能な低レイテンシと無制限スケールを手に入れた」道具です。この交換条件を受け入れられるかが選定の核心になります。
DynamoDBの中身（テーブル・アイテム・主キー・GSI、冪等性や条件付き書き込み）の詳細は、姉妹記事のDynamoDB シングルテーブル設計＆本番信頼性パターン完全ガイドにまとめています。本記事はその手前、**「そもそもDynamoDBを選ぶべきか」**に集中します。
3. SQL（RDB）とNoSQL（DynamoDB）の本質的な違い
公式の「SQLからNoSQLへ」の比較が、選定の土台です。RDBMSとDynamoDBの違いを公式表で整理します。
| 観点 | RDBMS（Aurora/PostgreSQL等） | DynamoDB |
|---|---|---|
| 最適ワークロード | アドホッククエリ・データウェアハウス・OLAP | Webスケール（SNS・ゲーム・メディア・IoT） |
| データモデル | 正規化された厳密なスキーマ（テーブル・行・列・リレーション） | スキーマレス。主キーのみ必須、非キー属性に制約なし。構造化／半構造化（JSON）を扱える |
| データアクセス | SQLが標準。豊富なツール群 | SDK（オブジェクト/ドキュメント/低レベル）。PartiQL（SQL互換）でselect/insert/update/delete |
| 性能 | ストレージ最適化。クエリ・インデックス・テーブル構造のチューニングが性能を左右 | コンピュート最適化。性能は主にハードとネットワークレイテンシの関数で、実装詳細は隠蔽される |
| スケール | 基本は垂直スケール（高速なハード）。分散も可能だが追加投資が要り、ファイル数/サイズに上限がありスケーラビリティに上限 | 分散クラスタで水平スケール。レイテンシを上げずにスループットを増やせる。1テーブルのアイテム数・総サイズに上限はない |
公式の設計思想の違いも決定的です。
In RDBMS, data can be queried flexibly, but queries are relatively expensive and don't scale well in high-traffic situations.（RDBMSではデータを柔軟にクエリできるが、クエリは相対的に高コストで、高トラフィック下ではスケールしにくい） In a NoSQL database such as DynamoDB, data can be queried efficiently in a limited number of ways, outside of which queries can be expensive and slow.（DynamoDBのようなNoSQLでは、限られた方法では効率的にクエリできるが、それ以外の方法では高コストかつ低速になりうる）
これが本質です。RDBは「柔軟だが高トラフィックで詰まる」、DynamoDBは「決まった引き方なら無敵だがそれ以外は苦手」。一行で言えば——
- RDB = 柔軟性のために設計する（実装やパフォーマンスを気にせず、後からクエリを足せる。正規化が重要）
- DynamoDB = 最頻出・最重要のクエリを最速・最安にするために設計する（データ構造をユースケースに合わせて作り込む）
4. DynamoDBが「向く」場面
次の条件が揃うほど、DynamoDBは強力です。
(1) アクセスパターンを事前に確定できる
DynamoDB設計の鉄則であり、公式が最も強く戒める点です。
you shouldn't start designing your schema for DynamoDB until you know the questions it will need to answer.（DynamoDBのスキーマ設計は、それが答えるべき質問を知るまで始めてはならない）
RDBは「まず正規化し、後からクエリを足す」ができますが、DynamoDBは逆。着手前にクエリの形（アクセスパターン）を列挙できることが前提です。要件が安定し、「このシステムは結局これとこれを引くだけ」と言い切れるなら、DynamoDBはその問いに対して最小コストで答え続けます。
(2) 超大規模・青天井の成長が見込まれる
公式は「1テーブルのアイテム数にも総サイズにも上限はない（There are no upper limits on the number of items per table, nor the total size of that table.）」と明言します。テーブルサイズに実用上の上限はなく、アイテム数・バイト数で制約されません。秒間数十万リクエスト級・200TB超のテーブルも本番で稼働しています。
「成功したら一気にスケールする可能性がある」「ピークが読めない」サービスで、RDBの垂直スケール上限やシャーディングの追加投資を回避できます。
(3) 予測可能な低レイテンシが要る
100ユーザーでも1億ユーザーでも一桁ミリ秒。スケールに伴って遅くならない設計が、ゲームのリーダーボード、カート、セッション、IoTのテレメトリのような「常に速くあるべき」ワークロードに効きます。
(4) サーバーレス・運用レスを最優先したい
Lambda・API Gateway・AppSyncとネイティブに統合し、サーバー管理ゼロでイベント駆動アーキテクチャを組めます。オンデマンドモードなら容量計画も不要で、トラフィックが無ければゼロまで縮みます。少人数・一人開発で運用負荷を最小化したいときの第一候補です。
(5) キーバリュー／ドキュメントのアクセスで足りる
「ユーザーIDでプロフィールを引く」「注文IDで注文と明細をまとめて取る」のように、キー（と限られたインデックス）で引ければ済むアクセスが中心なら、JOINが無いことは制約になりません。関連データを同居させる設計（シングルテーブル設計）で、JOIN相当をキー設計に置き換えられます。
私の実例: 決済コアの「冪等性・残高・台帳」のように、アクセスパターンが確定していて、整合性が最重要で、超大規模に耐える必要がある領域はDynamoDBに寄せました。条件付き書き込みとトランザクションで「正しさを設計で保証」できるからです。詳細は決済信頼性のケーススタディに。
5. RDB（Aurora/PostgreSQL）が「向く」場面
逆に、次の条件が一つでも強く効くなら、素直にRDBを選ぶべきです。ここで見栄を張ってNoSQL化するのが最頻出の失敗です。
(1) アドホックな柔軟クエリが要る
「後から思いついた条件で検索したい」「分析軸が頻繁に変わる」——公式がRDBMSの最適ワークロードを「アドホッククエリ」と名指しする通り、ここはRDBの独擅場です。DynamoDBで新しい引き方が増えるたびにGSI追加やデータ再設計が要るのに対し、RDBはWHERE句を変えるだけで済みます。
(2) JOINと関係整合性が中心
複数エンティティを関係として正規化し、外部キーで整合性を保ち、JOINで結合する——この世界観が中心なら、DynamoDBの非正規化・JOIN無しは逆らうコストが高すぎます。正規化された関係モデルが要件の本質なら、RDBが正解です。
(3) 集計・分析・レポーティング（OLAP）
GROUP BY、ウィンドウ関数、複雑な集計、BIレポート。公式がRDBMSを「データウェアハウス・OLAP」に最適と位置づける領域です。DynamoDBでこれをやろうとするとScan（テーブル全走査・高コスト）に頼ることになり、設計が崩壊します。
(4) アクセスパターンがまだ固まっていない／後から増える
スタートアップの初期、PoC、要件が流動的なプロダクト。「何を引くか」を着手前に確定できない段階では、RDBの「まず作って後で足す」柔軟性が開発速度で圧勝します。早すぎるDynamoDB採用は、要件が動くたびにキー設計をやり直す自傷行為になりがちです。
RDB（PostgreSQL/Supabase）を本番で選ぶ際の実戦的な設計（RLS・リアルタイム・Edge Functions）は、Supabase本番運用ガイドにまとめています。RDBを選ぶなら、こちらが具体的な実装指針になります。
Amazon RDS と Aurora の補足
RDBを選ぶ場合、AWS上の選択肢は主に Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL です。本記事はNoSQL vs RDBの軸が主題なので深入りはしませんが、ざっくり——
- RDS for PostgreSQL: 標準的なマネージドPostgreSQL。シンプルで素直。コスト効率が良く、まずはこれで十分なことが多い。
- Aurora PostgreSQL: PostgreSQL互換で、ストレージが自動拡張し、読み取りレプリカやServerless v2による弾力的スケールに強い。RDBのままスケールを伸ばしたいときの上位選択肢。
「RDBだがスケールも欲しい」なら、まずAurora（必要ならServerless v2）を検討するのが筋で、それでも足りない超大規模・特定アクセスパターンだけをDynamoDBに切り出す、という順序が安全です。
6. 意思決定フローチャート
軸を順に踏むと、ほとんどのケースは機械的に判定できます。上から順に評価してください。
- 集計・分析・アドホック検索が中心の用途か？ → YESなら RDB（Aurora/PostgreSQL）。（公式: OLAP・データウェアハウスはRDBMSの最適領域）
- 着手前にアクセスパターンを列挙して確定できるか？ → NO（後から自由に増える／探索的）なら RDB。要件が固まってから再評価。
- JOIN・複雑な関係整合性が要件の本質か？ → YESなら RDB。
- 想定スケールはRDB（Aurora）で十分か？ → YES（中〜大規模で収まる）なら、無理せず RDB。慣れた道具の生産性を取る。
- 超大規模・予測可能な低レイテンシ・サーバーレス運用レスが要件で、キー引き中心か？ → YESなら DynamoDB。
- 整合性が最重要なコア（決済・在庫・台帳）で、アクセスパターンが確定しているか？ → YESなら DynamoDB（条件付き書き込み・トランザクションで正しさを設計）。
- コアはDynamoDB向きだが、別途で分析・柔軟検索も必要か？ → YESなら ハイブリッド（次章）。コアをDynamoDB、分析をAuroraへ役割分割。
迷ったら原則は2つ。「アドホックに問い合わせたいならRDB」「確定した問いに超大規模で答えたいならDynamoDB」。そして判断に迷うほど要件が固まっていないなら、まずRDBで始めるのが安全です。RDB→部分的にDynamoDB化は現実的ですが、その逆（DynamoDB全面採用→やっぱりアドホック分析が要る）は痛みが大きいからです。
7. ハイブリッド構成：二者択一にしない
実システムの多くは、1つのエンジンですべてを賄おうとすると無理が出ます。正しい設計は、用途ごとに最適なエンジンへ役割分割することです。
パターンA：用途分割（コア vs 分析・検索）
- トランザクション整合性が要るコア（決済・在庫・カウンタ・台帳）→ DynamoDB。確定したアクセスパターンを低レイテンシ・無制限スケールで。
- アドホック分析・レポート・複雑検索 → Aurora PostgreSQL（または分析基盤）。柔軟なSQLで。
決済基盤での私の設計もこの分割でした。整合性クリティカルな書き込みはDynamoDBで「正しさを構造で保証」し、探索的なクエリが要る領域は別エンジンに逃がす。それぞれの道具を得意分野でだけ使うのが、結局いちばん速く・安く・安全です。
パターンB：Zero-ETLで分析だけ別エンジンへ
DynamoDBをコアに据えつつ分析もしたい場合、データを手作業でETLする必要はありません。公式がマネージドな連携を提供しています。
- Zero-ETL統合（Amazon Redshift）: DynamoDBのデータを、本番ワークロードに影響を与えずにRedshiftへ連携し、複雑な分析を実行できる。
- Zero-ETL統合（OpenSearch Ingestion）: 全文検索・ベクトル検索・セマンティック検索をDynamoDBデータに対して実行できる。
- S3エクスポート → Athena/Glue: フル/増分エクスポートでS3へ出し、Athenaでアドホック分析。本番テーブルを直接Scanせずに全件分析できる。
ポイントは、これらが本番のDynamoDBワークロードに影響を与えないこと。「OLTPはDynamoDB、OLAPは別エンジン」を、運用負荷を増やさず実現できます。
パターンC：DynamoDB Streamsでリアルタイム連携
DynamoDB Streamsは、アイテムの作成・更新・削除をニアリアルタイムの時系列で捕捉します。これをLambdaトリガに繋げば、書き込みをイベントとして他システム（検索インデックス、集計テーブル、RDBのリードモデル）へ非同期に反映できます。書き込みはDynamoDB、派生ビューは別所というCQRS的な分割の土台になります。
8. コスト観点：どちらが安いかは「形」で決まる
「DynamoDBとRDS、どっちが安い？」に一律の答えはありません。課金モデルが根本的に違うからです。
| 観点 | DynamoDB | RDB（Aurora/PostgreSQL） |
|---|---|---|
| 課金の単位 | リクエスト（オンデマンド）or 確保容量（プロビジョンド）＋ストレージ | 主にインスタンス稼働時間（＋ストレージ・I/O。Aurora Serverless v2は容量に応じた従量） |
| トラフィックゼロ時 | オンデマンドはゼロまで縮む（リクエスト0なら課金もほぼ0） | インスタンス課金は走り続ける（Serverless v2は最小ACUまで縮むが0ではない） |
| スパイク対応 | オンデマンドが瞬時に吸収 | スケールに時間・設計が必要 |
| 大量の柔軟クエリ | Scan多用でコスト膨張のリスク | SQLで効率的、ただし高トラフィックで詰まる |
| 無料利用枠 | 常時無料枠あり（25GBストレージ＋25RCU/25WCU、月2億リクエスト相当） | RDS/Auroraにも無料利用枠あり（条件付き） |
ざっくりの傾向:
- トラフィックが間欠的・スパイキー・読めない → DynamoDB（オンデマンド）がコスト効率的。使った分だけ。
- 常時一定の負荷がかかり続ける → RDBのインスタンス課金が素直に効く一方、DynamoDBはプロビジョンド＋リザーブドで対抗できる。
- 隠れコストに注意: DynamoDBは
Scan・FilterExpression・条件失敗・UpdateItemの課金など「数え方の罠」があります。アドホック分析をDynamoDBで無理にやるとコストが膨らみます。詳細はキャパシティ・コスト・性能設計ガイドに。
コストだけでエンジンを選ばないこと。間違ったエンジンを安く動かすより、正しいエンジンを正しく使う方が、総コスト（開発・運用・スケール時の作り直し）で必ず安くなります。
9. アンチパターン：RDBが正解なのに無理にDynamoDB化する
最も多く、最も高くつく失敗が、「カッコいいから／サーバーレスだから」でDynamoDBを選び、RDB向きの要件を押し込むことです。典型的な症状:
- GSIの乱立: 新しいクエリのたびにGSIを足し、デフォルトクォータ（テーブルあたりGSI 20個）に迫る。書き込みコストとクォータを浪費し、設計が破綻していく。
Scan地獄: アドホックな絞り込みをScan＋FilterExpressionで実装。フィルタは読んだ後に絞るだけで、課金は読んだ全件分。テーブル全走査が本番ホットパスに居座る。- アプリ側でのJOIN再実装: 複数テーブルを引いてアプリでマージ。RDBのJOINを手で書き直しているだけで、整合性もパフォーマンスも劣化する。
- 集計のためのフルスキャン:
GROUP BY相当を全件読み込みで実装し、コストと遅延が爆発する。 - 要件が動くたびのキー再設計: アクセスパターンが固まっていない段階で採用し、仕様変更のたびにデータモデルを作り直す。
これらはすべて、「DynamoDBが苦手なこと」を無理にやらせているサインです。一つでも当てはまるなら、その用途は（少なくともその部分は）RDBに戻すべきです。
逆方向の失敗もあります。RDBで超大規模・予測可能低レイテンシが必要なのに、シャーディングや手作りのスケール対策で消耗するケース。アクセスパターンが確定していて青天井のスケールが要るコアは、DynamoDBに切り出すのが正解です。
批判的に言えば——「全部DynamoDB」も「全部RDB」も、たいてい思考停止です。用途ごとに軸で判断し、必要ならハイブリッドにする。これが技術的負債を生まない選定です。
10. 移行の落とし穴
「後からエンジンを変えればいい」は、想像よりずっと高くつきます。選定時に移行コストまで織り込んでおくべきです。
- RDB → DynamoDB は「データモデルの再設計」: 単なるデータ移送ではありません。正規化された関係モデルを、確定したアクセスパターン起点で非正規化し直す必要があります。JOINで賄っていたクエリをキー設計に翻訳できなければ、移行は失敗します。先にアクセスパターンを棚卸ししてから着手すること。
- DynamoDB → RDB は「失った関係性の復元」: 非正規化で散らばったデータを正規化し直すのは骨が折れます。だからこそ最初の選定が効きます。
- アクセスパターンが本当に確定しているかの検証: DynamoDBへ寄せる前に、「向こう1〜2年で新しい引き方が増えないか」を厳しく問う。増えるなら、その部分はRDBに残すかハイブリッドにする。
- 無停止移行は設計が要る: 本番を止めずにデータ層を進化させるなら、二重書き込み（ミラーライト）→バックフィル→読み取り切替→旧撤去、という段階移行が定石です（シングルテーブル設計ガイドに詳述）。私はこの方式で決済基盤を1秒も止めずに更新しました。
移行を前提にしない選定が最善です。最初に軸で正しく選び、変わりうる部分はハイブリッドで吸収しておけば、大移行そのものを回避できます。
11. 選定チェックリスト（コードで言語化する）
判断軸を、レビュー可能な形で言語化しておくと、チーム/クライアントとの合意形成が速くなります。TypeScriptの型として「決定の根拠」を残す例です。
/** データ層選定の判断材料。各フラグは「設計レビューで合意した事実」を表す。 */
type DataLayerDecisionInput = {
/** 着手前にアクセスパターンを列挙して確定できるか */
accessPatternsKnownUpfront: boolean;
/** JOIN・複雑な関係整合性が要件の本質か */
needsJoinsAndRelations: boolean;
/** 集計・分析・アドホック検索（OLAP）が中心か */
needsAdHocAnalytics: boolean;
/** Aurora で収まらない超大規模・青天井の成長が見込まれるか */
needsHyperScale: boolean;
/** サーバーレス・運用レスを最優先するか */
prioritizeServerlessOps: boolean;
};
type Recommendation = "DynamoDB" | "RDB(Aurora/PostgreSQL)" | "Hybrid";
/**
* 公式の最適ワークロード（RDBMS=アドホック/OLAP, DynamoDB=Webスケール）に基づく素朴な判定。
* 注: これは思考の補助線であって、最終判断は要件全体の重み付けで行う。
*/
function recommendDataLayer(i: DataLayerDecisionInput): Recommendation {
// RDBが本質的に必要な要件は、まずRDBを基軸にする
const rdbCore = i.needsJoinsAndRelations || !i.accessPatternsKnownUpfront;
// DynamoDBが強く効く要件
const ddbCore =
i.accessPatternsKnownUpfront && i.needsHyperScale && i.prioritizeServerlessOps;
// コアはDynamoDB向きだが、分析・柔軟検索も要る → 役割分割
if (ddbCore && i.needsAdHocAnalytics) return "Hybrid";
if (rdbCore && i.needsHyperScale) return "Hybrid";
if (ddbCore) return "DynamoDB";
return "RDB(Aurora/PostgreSQL)";
}
このコードは「正解を自動生成する装置」ではなく、判断の根拠を明示し、見落としを防ぐためのチェックリストです。needsAdHocAnalytics が true なのに DynamoDB 単独を選ぼうとしている、といった矛盾を可視化できます。
おわりに：道具は軸で選ぶ
DynamoDBとAmazon RDS/Aurora(PostgreSQL)は、優劣ではなく得意分野が違う道具です。
- DynamoDB: アクセスパターンが確定し、超大規模・予測可能な低レイテンシ・サーバーレス運用レスが要る、キー引き中心のワークロード。
- RDB(Aurora/PostgreSQL): アドホックな柔軟クエリ・JOIN・集計分析（OLAP）が中心で、後からクエリが自由に増える要件。
- ハイブリッド: コアはDynamoDB、分析・検索はAuroraやRedshift/OpenSearchへ。多くの実システムの最適解。
公式が両者の最適ワークロードを「アドホック/OLAP」対「Webスケール」と明確に分けている以上、選定の答えは要件の中にあります。流行ではなく、アクセスパターン・スケール・整合性・クエリ自由度・運用負荷という軸で決める——これだけで、半年後の技術的負債のほとんどは避けられます。
私は、一人 × 生成AI（Claude Code）という体制で、設計判断は人間の検証ゲートを通す進め方を徹底し、DynamoDBとRDBを要件に応じて使い分けた本番システムを設計・運用してきました。**「うちのこのワークロードはどっちが正解か」**という発注前の意思決定から、ハイブリッド構成の設計、無停止移行まで伴走できます。
データ層の技術選定でお困りの方は、お問い合わせからご相談ください。 まずはアクセスパターンと整合性要件を一緒に棚卸しし、最適なエンジンの組み合わせを設計するところから始めます。