# DynamoDBはいつ使うべきか — Amazon RDS/Aurora(PostgreSQL)との使い分け技術選定ガイド（2026年版）

> DynamoDB（NoSQL）とAmazon RDS/Aurora（PostgreSQL）のどちらを選ぶべきかを、AWS公式仕様に忠実な意思決定フレームワークで解説。アクセスパターン・スケール・整合性・クエリ自由度という4軸、比較表、フローチャート、コスト観点、Zero-ETLを含むハイブリッド構成、無理にNoSQL化して失敗するアンチパターンまで、発注前の判断に答えます。

- 公開日: 2026-06-25
- 著者: 友田 陽大
- タグ: AWS, DynamoDB, PostgreSQL, アーキテクチャ設計, 技術選定, サーバーレス
- URL: https://tomodahinata.com/blog/dynamodb-vs-rds-aurora-postgresql-when-to-use-nosql-decision-guide

## 要点

- データ層は流行ではなく軸で選ぶ。判断軸は『アクセスパターンの確定度・スケール・整合性とクエリ自由度・運用負荷』の4つ。DynamoDBは事前確定パターンを最小コスト・最高スケールで、RDB(Aurora/PostgreSQL)はアドホックな柔軟クエリ・JOIN・集計分析を担う
- DynamoDBが向くのは、アクセスパターンが先に確定でき、超大規模・低レイテンシ・サーバーレスでJOINや探索的クエリが不要な場合。公式もRDBの最適ワークロードは『アドホッククエリ・データウェアハウス・OLAP』と明記している
- DynamoDBはJOINをサポートしない。設計はテーブルではなくアクセスパターンから始め、質問を知るまでスキーマ設計を始めてはならない。後からクエリが自由に増える要件はRDBが圧倒的に速く回せる
- 最頻出の失敗は『RDBが正解なのに無理にDynamoDB化する』こと。アドホック分析・複雑な集計・流動的な要件・小規模CRUDをNoSQLに寄せると、GSI乱立とScan地獄でコストも開発速度も悪化する
- 二者択一にしない。決済コアのようなトランザクション整合性はDynamoDB、分析や柔軟検索はAuroraへ、と役割分割するハイブリッドが実戦解。Zero-ETLやS3エクスポートで分析だけ別エンジンへ逃がせる

---

「とりあえず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 シングルテーブル設計＆本番信頼性パターン完全ガイド](/blog/dynamodb-single-table-design-reliability-idempotency-patterns)にまとめています。本記事はその手前、**「そもそも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が無いことは制約になりません。関連データを同居させる設計（[シングルテーブル設計](/blog/dynamodb-single-table-design-reliability-idempotency-patterns)）で、JOIN相当をキー設計に置き換えられます。

> **私の実例**: 決済コアの「冪等性・残高・台帳」のように、アクセスパターンが確定していて、整合性が最重要で、超大規模に耐える必要がある領域はDynamoDBに寄せました。条件付き書き込みとトランザクションで「正しさを設計で保証」できるからです。詳細は[決済信頼性のケーススタディ](/case-studies/payment-platform-reliability)に。

---

## 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本番運用ガイド](/blog/supabase-production-guide-nextjs-rls-realtime-edge-functions)にまとめています。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. 意思決定フローチャート

軸を順に踏むと、ほとんどのケースは機械的に判定できます。**上から順に**評価してください。

1. **集計・分析・アドホック検索が中心の用途か？**
   → YESなら **RDB（Aurora/PostgreSQL）**。（公式: OLAP・データウェアハウスはRDBMSの最適領域）
2. **着手前にアクセスパターンを列挙して確定できるか？**
   → NO（後から自由に増える／探索的）なら **RDB**。要件が固まってから再評価。
3. **JOIN・複雑な関係整合性が要件の本質か？**
   → YESなら **RDB**。
4. **想定スケールはRDB（Aurora）で十分か？**
   → YES（中〜大規模で収まる）なら、無理せず **RDB**。慣れた道具の生産性を取る。
5. **超大規模・予測可能な低レイテンシ・サーバーレス運用レスが要件で、キー引き中心か？**
   → YESなら **DynamoDB**。
6. **整合性が最重要なコア（決済・在庫・台帳）で、アクセスパターンが確定しているか？**
   → YESなら **DynamoDB**（条件付き書き込み・トランザクションで正しさを設計）。
7. **コアは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で無理にやるとコストが膨らみます。詳細は[キャパシティ・コスト・性能設計ガイド](/blog/dynamodb-capacity-cost-performance-on-demand-vs-provisioned-guide)に。

**コストだけでエンジンを選ばないこと**。間違ったエンジンを安く動かすより、正しいエンジンを正しく使う方が、総コスト（開発・運用・スケール時の作り直し）で必ず安くなります。

---

## 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に残すかハイブリッドにする。
- **無停止移行は設計が要る**: 本番を止めずにデータ層を進化させるなら、二重書き込み（ミラーライト）→バックフィル→読み取り切替→旧撤去、という段階移行が定石です（[シングルテーブル設計ガイド](/blog/dynamodb-single-table-design-reliability-idempotency-patterns)に詳述）。私はこの方式で決済基盤を1秒も止めずに更新しました。

**移行を前提にしない選定が最善**です。最初に軸で正しく選び、変わりうる部分はハイブリッドで吸収しておけば、大移行そのものを回避できます。

---

## 11. 選定チェックリスト（コードで言語化する）

判断軸を、レビュー可能な形で言語化しておくと、チーム/クライアントとの合意形成が速くなります。TypeScriptの型として「決定の根拠」を残す例です。

```ts
/** データ層選定の判断材料。各フラグは「設計レビューで合意した事実」を表す。 */
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 単独を選ぼうとしている、といった矛盾を可視化できます。

---

## FAQ

**Q. DynamoDBとRDS、結局どっちが安いですか？**
A. ワークロードの「形」で決まり、一律の答えはありません。トラフィックが間欠的・スパイキー・予測不能ならDynamoDB（オンデマンドはゼロまで縮む）がコスト効率的。常時一定負荷ならRDBのインスタンス課金が素直に効きますが、DynamoDBもプロビジョンド＋リザーブドで対抗できます。ただしアドホック分析をDynamoDBで無理にやると`Scan`課金でコストが膨らむので、**安さだけでエンジンを選ばない**ことが結局いちばん安く済みます。

**Q. DynamoDBでJOINはできますか？**
A. できません。公式が明言する通りDynamoDBはJOIN演算子をサポートしません。代わりにデータの非正規化と、関連データを同じキーに同居させる設計でJOIN相当を実現します。JOINと関係整合性が要件の本質なら、素直にRDB（Aurora/PostgreSQL）を選ぶべきです。

**Q. 後からアクセスパターンが増えたらどうなりますか？**
A. DynamoDBでは、新しい引き方のたびにGSI追加やデータ再設計が必要になりがちです（GSIはデフォルトでテーブルあたり20個）。だから**着手前にアクセスパターンを確定できること**がDynamoDB採用の前提です。「向こう1〜2年で引き方が自由に増える」見込みなら、その部分はRDBに残すか、ハイブリッドにします。RDBは`WHERE`句を変えるだけで新しいクエリに対応できます。

**Q. DynamoDBはどんなアプリに向きますか？**
A. 公式はWebスケールアプリ——ソーシャルネットワーク、ゲーム、メディア共有、IoT——を最適ワークロードに挙げます。具体的には、アクセスパターンが事前確定でき、超大規模・予測可能な低レイテンシが要り、キー引き中心で、サーバーレス運用レスにしたいケース。カート、セッション、リーダーボード、テレメトリ、そして整合性が最重要な決済・在庫・台帳などのコアが好例です。

**Q. 分析もしたいけどDynamoDBを使いたい。両立できますか？**
A. できます。コアをDynamoDBに置き、分析は別エンジンへ逃がすハイブリッドが定石です。**Zero-ETL統合**でRedshift（分析）やOpenSearch（全文/ベクトル/セマンティック検索）へ本番ワークロードに影響を与えず連携でき、**S3エクスポート→Athena**で全件分析もできます。「OLTPはDynamoDB、OLAPは別エンジン」を運用負荷を増やさず実現できます。

**Q. 迷ったらどちらから始めるべきですか？**
A. **要件が固まっていないなら、まずRDB**から始めるのが安全です。RDBは後からクエリを足せる柔軟性があり、RDB→部分的にDynamoDB化は現実的です。逆にDynamoDB全面採用後に「やっぱりアドホック分析が要る」となると痛みが大きい。アクセスパターンが確定し、超大規模・低レイテンシ・運用レスが要る部分だけをDynamoDBに切り出す、という順序を推奨します。

---

## おわりに：道具は軸で選ぶ

DynamoDBとAmazon RDS/Aurora(PostgreSQL)は、優劣ではなく**得意分野が違う道具**です。

- **DynamoDB**: アクセスパターンが確定し、超大規模・予測可能な低レイテンシ・サーバーレス運用レスが要る、キー引き中心のワークロード。
- **RDB(Aurora/PostgreSQL)**: アドホックな柔軟クエリ・JOIN・集計分析（OLAP）が中心で、後からクエリが自由に増える要件。
- **ハイブリッド**: コアはDynamoDB、分析・検索はAuroraやRedshift/OpenSearchへ。多くの実システムの最適解。

公式が両者の最適ワークロードを「アドホック/OLAP」対「Webスケール」と明確に分けている以上、選定の答えは**要件の中にあります**。流行ではなく、アクセスパターン・スケール・整合性・クエリ自由度・運用負荷という軸で決める——これだけで、半年後の技術的負債のほとんどは避けられます。

私は、一人 × 生成AI（Claude Code）という体制で、**設計判断は人間の検証ゲートを通す**進め方を徹底し、DynamoDBとRDBを要件に応じて使い分けた本番システムを設計・運用してきました。**「うちのこのワークロードはどっちが正解か」**という発注前の意思決定から、ハイブリッド構成の設計、無停止移行まで伴走できます。

**データ層の技術選定でお困りの方は、[お問い合わせ](/contact)からご相談ください。** まずはアクセスパターンと整合性要件を一緒に棚卸しし、最適なエンジンの組み合わせを設計するところから始めます。