自前DB（オンプレ）— MySQL / PostgreSQL を自分で立てる
📖 このページのゴール：自前DB（オンプレ）＝ DBサーバーを「自分で立てて、自分で運用する」やり方を、たとえ話で腹落ちさせます。前ページの SQLite（ノート1冊・サーバー不要）から一歩進んで、MySQL / PostgreSQL を本物のサーバーにインストールして動かす——そのかわり面倒も全部背負う、という立ち位置を理解しましょう。 ← 目次・はじめにへもどる
🗄 ひとことのたとえ
🟢 自前DB（オンプレ）は「レストランの厨房を、自分でまるごと構える」やり方です。
- 🏭 設備（コンロ・冷蔵庫・換気）＝サーバー（VM）を、自分で用意する。
- 👨🍳 料理人（運用する人）＝自分。 メニューづくりも、仕込みも、後片付けも、ガス漏れ対応も、ぜんぶ自分の責任。
出前を頼む（マネージド＝次の章）のではなく、厨房を構えて自分で全部まわすイメージです。自由は最大ですが、設備代も人手も、トラブル対応も、まるごと自分にのしかかります。
🔑 オンプレ（オンプレミス ＝ on-premises）＝「自社の敷地内（自分の管理下）に置く」という意味。サーバーが自宅でも会社でもクラウドのVMでも、運用を自分でやるなら「自前」です。
🔧 「自宅で構える厨房」だけでなく、「借りたテナントに自分で厨房を入れる」のもオンプレ流です。これがまさに、姉妹編の IaaS（サーバーだけ借りて中身は自分） の上にDBを立てるパターン。 🔗 動かす土台の話は姉妹編とつながっています → コンピューティングの選択肢：IaaS（サーバーを借りる）
🧩 何者？（しくみ）
🟢 やることは一言でいうと——
MySQL や PostgreSQL を、自分でサーバー（VM）にインストールして、自分で動かし続ける。
SQLite が「ノート1冊（ファイル）を直接読み書き」だったのに対して、自前DBは「受付の人（DBサーバー）を雇って、24時間立ち上げておく」形です。アプリはネットワーク越しにそのサーバーへ「これ保存して」「あれ出して」とお願いします。
土台（サーバー）は2通りあります。
| 土台 | イメージ | 例 |
|---|---|---|
| 自社DC・自宅の物理マシン | 自分の建物に、本物のサーバーを置く | 会社のサーバー室、自宅の常時起動PC |
| クラウドのVM（IaaS） | クラウドから箱（仮想マシン）を借り、その中に自分でDBを入れる | AWS EC2 / GCE などの上の PostgreSQL |
🔧 どちらでも「DBソフトの面倒は自分で見る」点は同じ。クラウドVMを使っても、それは「マネージド（おまかせ）」ではありません。OSの上は自分の領分です。
🛠 「自分でやること」一覧（ここが核心）
🟢 自前DBの正体は、この作業リストを全部自分で持つということに尽きます。
| やること | ざっくり言うと | サボると…… |
|---|---|---|
| インストール・設定 | DBソフトを入れて初期設定する | そもそも動かない |
| 🔧 パッチ（更新） | セキュリティ修正をあてる | 穴を突かれて侵入される |
| 🔧 バックアップ | 定期的に控えを取る | 壊れたら全データ消滅 |
| 🔧 冗長化（レプリケーション） | 同じDBを複製して予備を持つ | 1台死ぬとサービス全停止 |
| 🔧 チューニング | 速度が出るよう調整する | だんだん重くなる |
| 🔧 監視 | 異常をいつでも見張る | 倒れても誰も気づかない |
🔧 レプリケーション（replication ＝複製）＝同じ内容のDBを「本番＋予備」で持っておき、本番が倒れたら予備に切り替えること。厨房でいう「もう1台コンロを用意して、壊れても料理を止めない」備えです。
[ あなたのアプリ ]
│ 「保存して／出して」
▼
┌─────────────────────────────┐
│ サーバー（自分のVM / 物理マシン） │
│ ├ OS（自分で管理） │
│ ├ MySQL / PostgreSQL（自分で運用）│ ← パッチ・バックアップ
│ └ データ本体 │ ・冗長化・監視 ぜんぶ自分
└─────────────────────────────┘
↕（自分で立てた予備へ複製）
┌─────────────────────────────┐
│ 予備サーバー（レプリカ） │
└─────────────────────────────┘
🛠 代表サービス（実名）
🟢 「サービス」というより、自分のサーバーに入れるDBソフトそのものです。
| DBソフト | ひとこと | 置き場所の例 |
|---|---|---|
| PostgreSQL（ポストグレス） | 高機能で堅い、いま人気の定番 | 自社DC / 自宅PC / クラウドVM |
| MySQL（マイエスキューエル） | 昔から広く使われる定番 | 同上 |
🔧 どこに置いても「自分で入れて自分で運用」なら自前DB。たとえば AWS の EC2（IaaS）を1台借りて、その中に PostgreSQL を apt install で入れて運用する——これが典型です。次章の RDS は「同じ PostgreSQL でも運用をAWSに任せる」ので、別物として扱います。
👍 向いている / 👎 向かない
| 内容 | |
|---|---|
| 👍 向いている | ・完全な自由がほしい（OS・バージョン・拡張・配置を全部自分で決めたい） ・規制やデータ所在地の要件（「データは自社内／この国から出すな」） ・既存資産を活かす（もう自社サーバーや運用チームがある） ・特殊チューニング（普通のマネージドでは届かない細かい最適化をしたい） |
| 👎 向かない | ・運用が重い（パッチ・バックアップ・監視が毎日の仕事に） ・人手と知識が要る（専任のDB担当がいないと回らない） ・小規模には過剰（個人開発や小さなチームには重すぎる装備） |
🟢 ざっくり：「全部自分で決めたい＆その体力がある」なら自前。「楽したい・人がいない」なら向きません。
💰 コスト感
🟢 値段は「サーバー代だけ」では終わりません。
| かかるもの | 中身 | 大きさ |
|---|---|---|
| サーバー代 | 物理マシン or クラウドVMの料金 | 中 |
| 🔧 人件費 | 運用する人の時間（インストール〜障害対応） | いちばん大きい |
💡 見落としがちですが、「人の手間＝人件費」が最大のコストです。サーバー自体は安く見えても、「夜中にDBが倒れて叩き起こされる人」が必要、という値段が乗ってきます。
🔧 運用 / メンテ
🟢 ひとことで言うと——全部自分。
- パッチあて・バックアップ・監視を自分のスケジュールで回す。
- そして何より、障害対応も自分。サーバーが深夜に落ちたら、復旧するのもあなた（やチーム）です。
- 💾 「バックアップを取っている」だけでなく、本当に復元できるかを時々ためすところまでが運用です（鉄則：自前は復元まで自己責任）。
🏢 誰が使う？
| 立場 | 自前DB（オンプレ）は？ |
|---|---|
| 🧑💻 個人 / スタートアップ | 基本は避ける。運用が重すぎる → マネージド（次章）へ |
| 🏢 中堅ベンチャー | 特別な理由（コスト・規制）があれば一部だけ |
| 🏛 大企業 / 特殊要件 | 主役になり得る。規制・データ所在地・専任チーム・特殊最適化がある世界 |
🟢 個人やスタートアップは、まず迷わず「マネージド」へ。 厨房を自前で構えるより、出前（おまかせDB）のほうが圧倒的に身軽です。その話は次の章で。
📝 ことばメモ
- オンプレ（オンプレミス）＝自分の管理下で運用すること。運用を自分でやるなら、置き場所がクラウドVMでも「自前」。
- VM（仮想マシン）＝クラウドから1台ぶん借りる“箱”。この中にDBを入れる。
- パッチ＝ソフトの修正をあてる作業。とくにセキュリティ修正は必須。
- レプリケーション（冗長化）＝同じDBを複製して予備を持つこと。1台死んでも止めないための備え。
- チューニング＝速く動くように設定を調整すること。
🟢 ひとことで言うと
自前DB（オンプレ）は「厨房をまるごと自分で構える」スタイル。 MySQL / PostgreSQL を自分のサーバーに入れ、インストールからパッチ・バックアップ・冗長化・監視・障害対応まで全部背負います。自由は最大だが運用が重く、人件費が最大コスト。 個人やスタートアップは基本これを避け、運用を任せる「マネージド」へ進むのがおすすめです。