DynamoDB vs MongoDB
DynamoDB と MongoDB のどちらを使うべきですか？
予測可能なキーベースのアクセスパターンと手のかからないスケーリングを備えた、AWS 上のフルマネージドでサーバーレスなキーバリューかつドキュメントストアが欲しいなら DynamoDB を選びましょう。柔軟なアドホッククエリ、リッチな集計パイプライン、そしてセルフホストか主要な各クラウドでのマネージド運用の選択肢を備えたドキュメントデータベースが欲しいなら MongoDB を選びましょう。アクセスパターンが決め手です。
DynamoDB と MongoDB の概要
| 特性 | DynamoDB | MongoDB |
|---|---|---|
| データモデル | NoSQL のキーバリューとドキュメント、アイテムはテーブルにグループ化され、各アイテムは最大 400 KB | ドキュメントデータベース、BSON（JSON ライク）ドキュメントは最大 16 MB、コレクションにグループ化 |
| クエリ言語 / API | ネイティブ API（GetItem、Query、Scan、PutItem、…）と SQL 互換のクエリ言語 PartiQL | MongoDB Query API（MQL）と、多段階変換、結合（$lookup）、グループ化を行う集計パイプライン |
| 主なアクセスパターン | パーティションキー（および任意のソートキー）に対するキーベースの検索、スキーマは判明しているアクセスパターンを中心に事前設計 | 任意のフィールドに対する柔軟なクエリ、インデックスに支えられたアドホックなフィルターと集計 |
| セカンダリインデックス | グローバルセカンダリインデックス（独自のスループット、任意のキー）とローカルセカンダリインデックス（同じパーティションキー、パーティションあたり 10 GB の上限） | 任意のフィールドに対するセカンダリインデックス、複合、マルチキー、テキスト、地理空間、ワイルドカードインデックスを含む |
| 整合性モデル | デフォルトは結果整合性のある読み取り、リクエストごとに強い整合性のある読み取りが利用可能（単一の AWS リージョン内） | 調整可能な読み取り/書き込みの concern、プライマリからの読み取りはデフォルトで強い整合性 |
| スケーリングモデル | AWS が管理する自動パーティショニング、サーバーをプロビジョニングせずにスループットとストレージをスケール | クラスターにまたがるシャーディングによる水平スケーリング、レプリカセットが高可用性とフェイルオーバーを提供 |
| トランザクション | 複数アイテムにまたがる ACID トランザクション、単一の AWS リージョンに限定 | 複数ドキュメントの ACID トランザクション（4.0 以降）、シャードをまたぐものも含む（4.2 以降） |
| 料金モデル | リクエスト課金（オンデマンド）またはプロビジョンドキャパシティ、加えてストレージ、動かすサーバーなし | Atlas はクラスターベース（インスタンスサイズ/時間）で低コストの Flex ティアあり、セルフホストの Community エディションはインフラコストのみ |
| マネージド / サーバーレスの選択肢 | 完全にサーバーレスかつフルマネージド、AWS でのみ利用可能 | AWS、Google Cloud、Azure 上の Atlas マネージドサービス、セルフホストも可能。Atlas Serverless インスタンスは廃止され Flex ティアに置き換えられた |
| 最適なワークロード | 予測可能なキーアクセスを持ち、一貫した低レイテンシと最小限の運用が必要な大規模アプリ | 進化するスキーマ、アドホッククエリ、リッチな集計を持つアプリ、あるいはマルチクラウド / オンプレミスの可搬性が必要なアプリ |
DynamoDB が適している場合
- AWS 上にあり、データベース運用をゼロにしたい場合。 DynamoDB はサーバーレスです — パッチを当てるインスタンス、クラスター、キャパシティはありません。オンデマンドモードはトラフィックに合わせて自動でスケールします（キャパシティモード）。
- アクセスパターンが判明していてキーベースの場合。 データの読み取り方を中心にキーを設計できるとき、DynamoDB は実質的にあらゆる規模で一貫した低レイテンシの検索を実現します。ここはシングルテーブル設計が真価を発揮する場面です。
- リクエスト課金の料金体系が欲しい場合。 オンデマンドキャパシティでは、行った読み書きの分だけを支払い、アイドル状態のクラスターコストはありません。
- AWS との緊密な統合が必要な場合。 IAM、Lambda、ストリーム、そして広範な AWS エコシステムとのネイティブな結びつきが、つなぎのコードを減らします。
MongoDB が適している場合
- クエリがアドホックまたは探索的な場合。 MongoDB では任意のフィールドでフィルターしインデックスを張ることができ、すべてのアクセスパターンを事前計画することなく、リッチなサーバーサイドの集計（コレクションをまたぐ結合を含む）を実行できます。
- クラウド間やオンプレミスでの可搬性が必要な場合。 MongoDB はセルフホスト、または AWS、Google Cloud、Azure にまたがる Atlas 上で動作します。DynamoDB は AWS 専用です。
- ドキュメントが大きい、または深くネストしている場合。 MongoDB の 16 MB のドキュメント上限は DynamoDB の 400 KB アイテム上限よりはるかに大きいです（DynamoDB の制約）。
- スキーマが素早く進化する場合。 柔軟なドキュメントに第一級のセカンダリインデックスが加わり、堅固な事前のキー設計なしに変化の速いモデルに適します。
DynamoDB を扱う
DynamoDB を選んでも、日々テーブルを参照し、クエリを実行し、アイテムを編集する高速な手段は依然として必要です。DynoTableは DynamoDB のためのネイティブなデスクトップ GUI です。アイテムの参照とインライン編集、キー条件とフィルターの構築、そして SQL ワークベンチと AI アシスタントでのクエリができます。MongoDB の「何でもクエリできる」メンタルモデルから来たなら、SQL ワークベンチは、DynamoDB のアクセスパターンのルール内にとどまりながらリレーショナル的な形のクエリを表現するのに役立ちます。
ドキュメントを離れずに式を構築するには、無料の DynamoDB Expression Builder が、そのまま貼り付けられる SDK、CLI、PartiQL 出力とともにキー条件、フィルター、更新式を生成します。そして、キーバリューストア向けのモデリングが初めてなら、DynamoDB でのデータモデリング方法ガイドが、エンティティとアクセスパターンをキーに落とし込む手順を解説します。
よくある質問
DynamoDB は MongoDB より速いですか？
どちらも一律に速いわけではありません — ワークロードとデータのモデル化の仕方によります。DynamoDB はキーベースのアクセスに対して大規模でも一貫した低レイテンシのパフォーマンスを実現するよう設計されており、MongoDB はインデックス付きおよびアドホックなクエリで非常に高速になり得ます。実世界のレイテンシには、エンジンよりも適切なデータモデルの方が重要です。
DynamoDB は MongoDB を置き換えられますか？
場合によります。アクセスパターンが予測可能でキーベースであれば、DynamoDB は MongoDB を置き換え、運用上のオーバーヘッドの大半を取り除けます。多くのフィールドにまたがるアドホッククエリやサーバーサイド集計に依存しているなら、移行にはまず DynamoDB のキーを中心にデータを再モデル化する必要があります — DynamoDB でのデータモデリング方法を参照してください。
DynamoDB は MongoDB をベースにしていますか？
いいえ。両者は異なる会社による無関係の製品です。DynamoDB は AWS がマネージドするデータベースで、その設計の系譜は Amazon 社内の Dynamo の取り組みにさかのぼります。一方 MongoDB はオープンソースに根ざした別個のドキュメントデータベースです。両者は「NoSQL」というラベルを共有しますが、コードベースは共有していません。
関連
- シングルテーブル設計と DynamoDB でのデータモデリング方法を学びましょう。
- 無料の DynamoDB Expression Builder で式を構築しましょう。
- DynoTable をダウンロードして、SQL ワークベンチと AI で DynamoDB を参照、クエリ、編集しましょう。
最終確認日 2026-07-12、公式の AWS DynamoDB デベロッパーガイドおよび MongoDB のドキュメントに照らして確認済み。MongoDB はそれぞれの所有者の商標であり、ここでは識別目的でのみ参照しています。