データの置き場所ガイド — RDB/NoSQL/キャッシュ/ストレージ

このページは入口（ハブ）です。まずここを読んで、上から順に各ページへ進んでください。

アプリを作ると必ず出てくるのが「このデータ、どこに・どうやって置く？」という問題です。リレーショナルDB（RDS・Aurora・自前・SQLite）／NoSQL（DynamoDB・MongoDB・Firestore）／キャッシュ（Redis など）／ファイル置き場（S3 など）——名前は聞いても、「結局どれをいつ使うの？」はモヤッとしがち。

この文書は、姉妹編 コンピューティングの選択肢（アプリを“どこで動かすか”） の続編。今度は “データを どこに置くか” を、AWS・Firebase・Supabase など今どきの具体例で、完全未経験の人でも腹落ちするように整理します。

いちばん大事な考え方：2つの軸で選ぶ 🧭

データの置き場所は、たくさんあって混乱しますが、2つの軸で考えるとスッと整理できます。

軸①：データの「形」は？
   かっちりした表（行と列・関係でつなぐ）  →  リレーショナルDB（RDB / SQL）
   ゆるい・多様・とにかく大量/高速        →  NoSQL（KV / ドキュメント / …）

軸②：運用をどこまで「任せる」？  ← 姉妹編「コンピューティングの選択肢」のはしごと同じ！
   ファイル(SQLite) → 自前(オンプレ) → マネージド(RDS) → クラウドネイティブ(Aurora) → サーバーレス(DynamoDB/Firestore)
   （自分でやる・自由）──────────────────────────────────→（任せる・楽）

そして、この2軸とは別腹で、よく一緒に使う2つがあります。

  • 🏃 キャッシュ（Redis など）：DBの手前に置く「速さのための一時置き場」。
  • 📦 オブジェクトストレージ（S3 など）：画像・動画などの「大きいファイル置き場」。

🍽 たとえで早見

置き場所 たとえ 何のため
RDB（SQL） きっちりした表計算＋伝票 関係のあるデータを正確に。まず第一候補
NoSQL 中身バラバラでも入る大きなカゴ 大量・高速・柔軟（複雑な突き合わせは苦手）
SQLite ノート1冊（ファイル1個） サーバー不要。手軽・組み込み・エッジ
キャッシュ 机の上の付箋・手元の控え よく使う答えを置いて高速化（古くなる点に注意）
オブジェクトストレージ 貸し倉庫 大きいファイル。DBには「倉庫の場所＝URL」だけ

🔑 最初に覚える鉄則

  • 📦 大きいファイル（画像・動画）はDBに入れない。 ファイルは S3 などの倉庫へ、DBには URL（場所）だけ。初心者が必ずやる失敗です。
  • 🔒 そのデータは誰のもの？ 持ち主と権限を意識（姉妹教材の RLS＝データ分離と地続き）。
  • 🏃 キャッシュは“控え”、真実の源はDB。 消えても困らない一時データだけ置く。
  • 🧭 迷ったら、まず PostgreSQL 系のマネージド（Supabase / Neon / RDS）。 SQLは普遍で移行もしやすく「とりあえず間違いない」。NoSQL は“理由があるとき”に。

読み方

  • 各ページは「📖 ゴール → たとえ → しくみ → 代表サービス → 向き/不向き → コスト/運用 → 誰が使う → ことばメモ」。
  • むずかしさの目印：🟢 基礎（全員） ／ 🔧 応用（読み飛ばしOK）。
  • 急ぐ人は、まとめ（フローチャート＆早見表）だけでも判断material になります。

目次

第1部　まず全体像と基礎

第2部　SQL系をどう動かす（運用のはしご）

第3部　NoSQL

第4部　速さとファイル（別腹の2つ）

まとめ・付録

この文書の到達点

最後まで読むと、こんなことができるようになります。

  • 「RDB／NoSQL／キャッシュ／オブジェクトストレージ」の役割分担をたとえで説明できる
  • RDS・Aurora・DynamoDB・Firestore・SQLite・Redis・S3 が2軸のどこにいるかわかる
  • 自分の用途・立場（個人〜大企業）から、最初のデータ設計の一手を選べる
  • 「大きいファイルはDBに入れない」「キャッシュは控え」など、つまずきポイントを避けられる