DynamoDB / MongoDB / Firestore — 代表3つの使い分け
📖 このページのゴール：NoSQL の「とりあえず触る3つ」を、たとえ＋表でつかむ。「超スケールなら DynamoDB」「柔軟に速く作るなら MongoDB」「リアルタイム＆モバイルなら Firestore」——この一行が言えるようになればOK。 ← 目次・はじめにへもどる
前のページ（NoSQL とは）で、NoSQL ＝ 中身の形がバラバラでも入る大きなカゴ 🧺 だと見ました。でも「NoSQL を使おう」と思った瞬間、次の壁が来ます——で、どれ？ 種類も製品も多すぎる。
そこでこのページは、初心者が実際に名前を聞く代表3つだけに絞ります。同じ「NoSQL」でも、得意な場面がぜんぜん違うのがミソです。
🧺 まず一言のたとえ（3つの性格）
| サービス | ひとことのたとえ | 性格 |
|---|---|---|
| 🦖 DynamoDB | 超巨大な自動倉庫：荷物がいくら増えても係員いらずで勝手に広がる。ただし棚の置き方を先に決める必要がある | とにかく大量・高速・運用ゼロ。設計はお堅い |
| 🍃 MongoDB | 何でも放り込めるノート：JSONっぽい紙をそのまま貼っていける。書き方が自由で速い | 柔軟・開発が速い。みんなが慣れてる定番 |
| 🔥 Firestore | みんなで同時に見るホワイトボード：誰かが書くと全員の画面に即反映 | リアルタイム・モバイル/Web向け。個人開発の友 |
🟢 3つとも「ドキュメント（JSONっぽい塊）」を扱えます（DynamoDB は KV ＋ ドキュメントの両刀）。形が違うのは中身というより得意な使い方です。
🧩 何者？（それぞれ数行で）
🦖 DynamoDB（AWS）
- KV／ドキュメント型の、AWS製サーバーレスNoSQL。サーバー（受付の人）を一切立てず、使った分だけ課金（従量）、アクセスが増えれば自動でスケール。運用はほぼゼロ。
- 超大規模・超高速に強いのが最大の売り。何百万リクエスト来てもビクともしない設計。
- 代わりに肝なのが——🔧 「どう探すか（アクセスパターン）」を先に決めてから設計すること。RDB のように「あとから好きな条件で柔軟に検索」は苦手で、想定外の探し方をすると遅い・できない・高い、になりがち。先に使い方、あとで設計、ではなく設計の時点で使い方が決まっている世界です。
🍃 MongoDB
- ドキュメント型（中身は JSON っぽい塊＝BSON）。「ユーザー1人＝1枚の紙」みたいに、塊のまま保存・取得できる。
- スキーマ（表の設計図）がゆるいので、項目が増えても気軽。柔軟で開発が速い＝プロトタイプや仕様が動くアプリと相性◎。
- 自前で立てることもできるが、いまの定番は Atlas（アトラス） というマネージド版（運用をMongoDB社が代行。AWS/GCP/Azure上で動く）。「まずは Atlas」で迷わない。
🔥 Firestore（Google / Firebase）
- ドキュメント型。Google の Firebase ファミリーの一員で、フロント（アプリ画面）から直接読み書きできるのが特徴。
- 看板機能が ⚡ リアルタイム同期：データが変わると、見ている全員の画面に自動で即反映（チャット・共同編集・通知に強い）。
- Firebase Authentication（ログイン機能）と相性抜群で、「誰がどのデータを読めるか」をルールで書ける。モバイル/Web 向けで、サーバーをほとんど書かずにアプリが立ち上がる——個人・スタートアップの定番。
- 🔗 ログイン・権限まわりは姉妹教材の Firebase / Supabase 編と地続き。あちらも合わせて読むと「フロントから直 DB」のイメージがつかめます。
🛠 比較表（ここだけ見ても判断できる）
| 観点 | 🦖 DynamoDB | 🍃 MongoDB | 🔥 Firestore |
|---|---|---|---|
| 提供元 | AWS | MongoDB社（Atlasでマネージド） | Google / Firebase |
| 種類 | KV ＋ ドキュメント | ドキュメント（JSONっぽい） | ドキュメント |
| いちばんの強み | 超スケール・高速・運用ゼロ | 柔軟・開発が速い | リアルタイム同期・モバイル/Web |
| 課金 | 従量（使った分） | 容量・規模ベース（Atlas） | 従量（読み書き回数など） |
| スケール | 自動・ほぼ無限 | 水平分割（シャーディング）対応 | 自動 |
| 検索の柔軟さ | 🔧 弱め（先に設計が要る） | 強め（後からクエリしやすい） | 中（できることに制約あり） |
| 運用の手間 | ほぼゼロ（サーバーレス） | Atlasなら少ない | ほぼゼロ |
| ログイン連携 | AWS側で別途 | 別途 | Firebase Authと一体で楽 |
| ロックイン | 強め（AWS） | 中（どこでも動く） | 強め（Google/Firebase） |
| こんな人に | 大量トラフィックを捌くサービス | 仕様が動く・素早く作る | アプリを少人数でサッと立てる |
👍 向いている / 👎 向かない
🦖 DynamoDB
- 👍 桁違いのアクセス（数百万〜）／カートやセッションなど読み書きの形が決まっている処理／運用に人を割けない
- 👎 「あとから自由に色んな条件で集計・検索したい」用途／設計を固める前のふわっとした探索段階
🍃 MongoDB
- 👍 仕様が変わりやすい開発／JSON のまま素直に持ちたい／柔軟なクエリも欲しい
- 👎 RDB 的な厳密な整合性（ぜんぶ成功かぜんぶ取消）をガッチリ効かせたい複雑な取引処理
🔥 Firestore
- 👍 チャット・共同編集・通知など即時反映が要る／モバイル/Web でサーバーを書かずに作りたい／ログインとセットで小さく始める
- 👎 大量データの複雑な集計・分析／RDB 的な多テーブル結合が中心の業務システム
💰 コスト感・🔧 運用
- 🦖 DynamoDB：基本従量。小さいうちは安いが、設計を外すと読み書き回数がかさんで高くなりがち。運用の手間はほぼゼロ。
- 🍃 MongoDB（Atlas）：規模・容量に応じた料金。Atlas を選べば運用は軽い（自前運用はバックアップ等を自分で背負う）。
- 🔥 Firestore：読み書き回数ベースの従量。趣味〜小規模なら無料枠で足りることも。アクセスが跳ねると課金も跳ねる点だけ注意。
🏢 誰が何を使う？（ざっくり）
| 立場 | よくある選び方 |
|---|---|
| 👤 個人 / スタートアップ | Firestore（ログイン込みでサッと） or 用途次第で DynamoDB。まずは小さく |
| 🚀 中堅ベンチャー | 主役は RDB、用途別に DynamoDB（高トラフィック部分）を足す |
| 🏢 大企業 | DynamoDB を超大規模処理に、MongoDB を柔軟用途に、と適材適所で併用 |
🧭 どんな時にどれ？（合言葉）
超スケールの KV・運用ゼロで捌きたい → 🦖 DynamoDB（ただし先にアクセスパターン設計）
柔軟に・速く作りたい（仕様が動く） → 🍃 MongoDB（迷ったら Atlas）
リアルタイム ＆ モバイル/Web で軽く → 🔥 Firestore（Firebase Authと一緒に）
⚠️ そして最後にいちばん大事なこと——特別な理由（超スケール・特定のアクセスパターン・リアルタイム）が無ければ、まずは RDB（PostgreSQL系のマネージド）でよい。NoSQL は「これが要る」と言える理由ができてから選ぶのが、初心者がいちばん損しない道です。
🌩 クラウドならではの強み — 桁違いのスケール＆リアルタイム（🟢 基礎）
DynamoDB や Firestore は、ただのDBではなく 巨大クラウド（AWS / Google）のインフラに乗ったサービスです。だから、自前で立てた普通のRDBにはまねしにくい強みを、ほぼ設定なしで手に入れられます。ここが「特別な理由」になることもあります。
① 桁違いのスケール（同時アクセスに強い）
- Firestore：1つのデータベースで 約100万の同時接続まで耐える設計。アクセスが急増しても、こちらは何もしなくても自動でスケールします。
- DynamoDB：実質上限なしに近いスケールで、どれだけ増えても数ミリ秒で返す速さ。世界規模のサービスでも使われています。
- 👉 普通のRDB（自前の PostgreSQL/MySQL）は、同時接続が増えるとコネクション数の上限にぶつかり、読み取りレプリカ・シャーディング（水平分割）・コネクションプールなどを自分で作り込む必要があります。クラウドNoSQLは、その重労働を肩代わりしてくれます。
② リアルタイム — 変化がブラウザに“勝手に”届く
- Firestore は、クライアントが「このデータを見張って」と購読（onSnapshot）しておくと、誰かがデータを変えた瞬間、見ている全員の画面へ自動で反映されます。チャット・共同編集・ライブ更新が、ほぼコードを書かずに作れます。
- 👉 普通のRDBには、この「変化をブラウザへ押し出す」機能はありません。自分で WebSocket／ポーリング を組むか、別のしくみ（前作 ChatGPTクローンの SSE など）を足す必要があります。
💡 ちなみに Supabase も Postgres の上に Realtime（変更をブラウザへ流すしくみ）を載せていて、RDBでも“リアルタイムっぽい”ことはできます。そして「ブラウザから直接DBを触る」という、ふつうと違うけれど強力な作り方は、Supabase（RLS）と Firestore（セキュリティルール）の共通点です。→ くわしくは 付録B クライアントから直接DB？。
📝 ことばメモ
- アクセスパターン：データを「どんな条件で・どう探すか」の決まりごと。DynamoDB はこれを先に決めて設計する。
- Atlas（アトラス）：MongoDB のマネージド版（運用おまかせのクラウド版）。
- リアルタイム同期：データが変わると、見ている全員の画面に自動で即反映されるしくみ。
- Firebase Authentication：Google/Firebase のログイン機能。Firestore と一体で使える。
🟢 ひとことで言うと
NoSQL の代表3つは性格が別物。超スケール＆運用ゼロなら DynamoDB（先に設計）／柔軟に速く作るなら MongoDB（Atlas）／リアルタイム＆モバイルなら Firestore（Firebase Authと相性◎）。そして——特別な理由が無ければ、まずは RDB で素直に。