アプリの心臓はデータベースだ．そしてDBの設定ミスは，情報漏洩とデータ消失という最悪の事故に直結する．VPSでDBを安全に動かす勘所を整理する．

対象はVPSでアプリとDBを動かす個人開発者．読み終えたとき，「とりあえず動く」から「安全に運用できる」へ一段上がれる状態を目指します．

なぜDB運用を軽く見てはいけないか

DBは最も価値が高く，最も復旧が難しい資産だ．アプリは作り直せても，失われたユーザーデータは戻らない．

そしてDBの外部公開はインターネット最悪の事故の一つだ．設定ひとつで全データが世界に晒される．勘所を押さえることは必須教養だ．

勘所1：DBを外部に公開しない

最優先はDBポートをインターネットに晒さないこと．同一VPS内のアプリからだけ繋ぐなら，localhostバインドで十分だ．

PostgreSQLをlocalhostのみで待ち受け

# postgresql.conf
listen_addresses = 'localhost'
# 確認
sudo ss -tlnp | grep 5432   # 127.0.0.1だけならOK

勘所2：強いパスワードと最小権限

アプリ用ユーザーは必要なDBへの必要な権限だけに絞る．superuserでアプリを動かしてはいけない．

パスワードは長くランダムに．そして.envに置きGitに入れないのが鉄則だ．

勘所3：バックアップとリストアを両方試す

取れていても戻せなければ無意味だ．定期ダンプを取り，実際にリストアできるか必ず一度試す．

毎日ダンプ（cron）とリストア確認

0 3 * * * pg_dump -U app mydb | gzip > /home/deploy/backup/mydb-$(date +%F).sql.gz
# リストア確認（別DBへ）
gunzip -c mydb-2026-06-10.sql.gz | psql -U app restore_test

勘所4：メモリと接続数を見積もる

DBはメモリを食う．接続数が増えるとメモリ不足でアプリごと落ちる．用途に応じてメモリに余裕のあるVPSを選ぶ．

アプリ側でコネクションプールを使い，無制限に接続を張らない設計にするのも安定運用の要だ．

勘所5：文字コードとタイムゾーンの落とし穴

文字化けは後から直すのが地獄だ．DB作成時にUTF-8(utf8mb4)を明示し，絵文字や多言語に耐えるようにする．

タイムゾーンも最初に決める．サーバー・DB・アプリで基準時刻を揃えると，日時バグの大半を防げる．

補論：DBは「速いディスク」と「巻き戻し」で安心が変わる

DBのレスポンスはディスク速度に大きく左右される．遅いストレージのVPSでは，クエリが詰まりアプリ全体が重くなる．

高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─ はNVMe SSDでDBの読み書きが軽快に進み，スナップショットを取っておけば「移行・アップグレード前の状態」へ丸ごと戻せる．DB運用の試行錯誤を安全に行える基盤だ．

DB管理画面を公開するなら，取り扱い400種類以上のドメイン取得サービス─ムームードメイン─ のドメイン＋HTTPS＋IP制限で固めるのが基本．むやみに公開しないことが最大の防御になる．

よくある質問

Q1：DBはアプリと同じVPSに置いていい？

個人開発・小規模なら問題ない．localhost接続にでき，構成もシンプルになる．規模が育てばDBを別サーバーやマネージドへ分離する．

Q2：PostgreSQLとMySQLどちらを選ぶ？

どちらでも良いが，型の厳密さや高度な機能ならPostgreSQL，枯れた情報量とWordPress連携ならMySQLが選ばれやすい．迷ったらPostgreSQLで困らない．

Q3：マネージドDBを使うべき？

運用負荷を下げたいなら有効だが，固定費と原価管理を優先するならVPS上で自前運用が合理的だ．バックアップさえ堅実なら個人開発では自前で十分戦える．

まとめ ― DBは「公開しない・戻せる・速い」の3点で守る

DB運用の核心は，外部に公開しない・確実に戻せる・十分に速いの3点だ．派手な最適化より，この基本が事故を防ぐ．

まずはlocalhostバインドの確認とバックアップのリストア検証から．この2つができていれば，あなたのデータは最悪の事態から守られている．