データベースの性能を上げる話（パフォーマンスチューニング総論）と、データベースを本番で安全に運用し続ける話は別物です。後者で問われるのは「速さ」ではなく——壊れたとき戻せるか、落ちたとき止まらないか、混んだとき詰まらないか、攻撃されたとき守れるか、進化させるとき止めずに済むか。
この記事は、PostgreSQL を本番で運用するための全体地図です。バックアップ・HA・接続・監視・セキュリティ・アップグレードを、「事故が起きる前提」で並べ直します。各論は個別記事に譲り、本稿は運用の意思決定と優先順位に集中します。受託開発で「Postgres を任せて大丈夫か」を見極める発注者にも、運用を引き継ぐエンジニアにも効く内容です。
この記事のルール：仕様・既定値・PostgreSQL 18 の新機能は PostgreSQL 18 公式ドキュメント（2026年6月時点） に基づきます。PgBouncer・RDS 等のベンダー固有事項はその旨を明記します。マネージドサービスは多くの運用を代行するため、ここで述べる手作業の一部は不要になります（その境界も本文で示します）。
1. 本番運用の5つの問い
運用設計は、次の5つに答えられれば8割完成します。上から「失うと致命的」な順です。
| # | 問い | 失敗すると | 武器 | 深掘り |
|---|---|---|---|---|
| 1 | 壊さない | データ消失（=廃業級） | バックアップ・PITR | §2 / バックアップ記事 |
| 2 | 止めない（障害時） | ダウンタイム・SPOF | レプリケーション・HA | HA記事 |
| 3 | 止めない（変更時） | デプロイで全断 | ゼロダウンタイムDDL | 無停止DDL記事 |
| 4 | 詰まらせない | 接続枯渇・スロー化 | 接続プーリング・監視 | 接続プーリング記事 |
| 5 | 守る | 情報漏洩・不正アクセス | 最小権限・TLS・SCRAM | セキュリティ記事 |
| + | 進化させる | 塩漬け・EOL | 無停止アップグレード | 論理レプリケーション記事 |
2. 壊さない：バックアップは「戻せる」が正義
最も重い問いから。**バックアップの目的は「取ること」ではなく「戻せること」**です。テストしていない復旧手順は、存在しないのと同じ。
PostgreSQL のバックアップは公式に3方式（詳細はバックアップ＆PITR記事）。
| 方式 | 何ができる | 限界 |
|---|---|---|
論理（pg_dump） | 稼働中に一貫スナップショット。可搬・選択復元・バージョン跨ぎ | DB単位。ロール/テーブルスペースは別途 pg_dumpall |
| 物理（ファイル） | クラスタ丸ごとコピー | サーバー停止が必須（または pg_basebackup） |
| 継続的アーカイブ（WAL） | ベースバックアップ＋WAL継続退避で任意の時点に復旧（PITR） | 設定が複雑・クラスタ単位 |
決定的な違いは**RPO（どれだけ失うか）**です。
- 夜次の
pg_dump→ 最悪、前回ダンプ以降（最大24時間）を失う。 - 継続的アーカイブ → 公式曰く「ベースバックアップ以降の任意の時点に復旧できる」。WAL を退避し続けるので、データ損失はほぼゼロにできる。
発注者・運用者への含意：本番の基幹DBで「夜次ダンプだけ」は危険です。継続的アーカイブ（またはマネージドの PITR） を前提に、さらに「復旧訓練を定期実施」して初めて「壊さない」が成立します。マネージド（RDS/Aurora/Cloud SQL）はスナップショット＋WALアーカイブを自動化し、
archive_commandやpg_basebackupを手で運用せずに PITR を提供します（ベンダー機能）。
3. 止めない（障害時）：レプリケーションとHA
サーバーは壊れます。ディスクは飛び、AZは落ちる。SPOF（単一障害点）を作らないのが「止めない」の核心です。
PostgreSQL の主要なHAは物理ストリーミングレプリケーション——プライマリのWALをスタンバイへ流し、ほぼ最新の複製を待機させます（詳細はHA記事）。同期/非同期を選べ、リードレプリカで読み取りを逃がせます。
ここで最重要の事実（公式が明記）：
PostgreSQL は、プライマリの障害を検知してスタンバイに通知するシステムソフトウェアを提供しない。
つまり PostgreSQL コアは自動フェイルオーバーを内蔵していません。障害検知・昇格（pg_promote()）・IPの付け替え・スプリットブレイン防止（STONITH）は、Patroni などの外部ツールで組む必要があります。
これがマネージドの最大の価値です。RDS/Aurora の Multi-AZ は、この「検知＋自動フェイルオーバー＋エンドポイント切替」を代行します。自前運用なら Patroni 等の構築・運用コストを見積もる必要があり、この一点だけでもマネージドを選ぶ理由になり得ます。
同期/非同期は耐久性とレイテンシのトレードオフです。synchronous_commit の既定は on、synchronous_standby_names が空なら非同期（コミットはスタンバイを待たない＝速いが、プライマリ全損時に直近のコミットを失い得る）。「1件も失えない」要件なら同期を選び、レイテンシ増を受け入れます。
4. 止めない（変更時）：ゼロダウンタイムDDL
障害だけでなく、自分のデプロイでも本番は止まります。ALTER TABLE の多くは ACCESS EXCLUSIVE ロックを取り、公式の定義どおりSELECT すらブロックします。
危険なのは「ロック待ちの連鎖」です。長時間クエリの後ろでマイグレーションがロック待ちに入ると、その後ろに新規クエリが全部積み上がり、実質全断になります。対策（詳細は無停止DDL記事）：
-- マイグレーションは「世界を止める前に諦める」。短い lock_timeout で即失敗させ、リトライする
SET lock_timeout = '3s';
ALTER TABLE orders ADD COLUMN note text; -- 定数デフォルトなら PG11+ で書き換え不要＝高速
- 列追加：定数デフォルトはテーブルを書き換えず高速。
volatileなデフォルトは全書き換え（避ける）。 - NOT NULL / 制約：
ADD CONSTRAINT ... NOT VALID（即コミット）→VALIDATE CONSTRAINT（弱いロックで検証）の2段階。 - 索引：
CREATE INDEX CONCURRENTLY（書き込みを止めない）。 - PostgreSQL 18 は
NOT NULL制約にNOT VALIDを付与可能になり、無停止の NOT NULL 追加がより素直になりました。
5. 詰まらせない：接続プーリングと監視
接続は「プロセス」
PostgreSQL は接続ごとにOSプロセスを1つ forkします（公式アーキテクチャ）。max_connections の既定は 100。これを上げるのは解決策ではありません——各バックエンドはメモリを消費し、work_mem もバックエンド単位で乗算されるからです。
正解は接続プーリング。アプリ↔DB の間にプーラー（PgBouncer 等）を挟み、物理接続を少数で使い回す。特にサーバーレス（Lambda/エッジ）は直結厳禁——スパイク時に接続ストームで max_connections を突破して落ちます。トランザクションモードのプーラー（PgBouncer / RDS Proxy / Supabase Supavisor）が必須です（詳細・注意点は接続プーリング記事）。
監視は「症状」で鳴らす
最低限、これは常時見ます。
-- 詰まりの兆候：長時間 active / idle in transaction / ロック待ち
SELECT pid, state, wait_event_type, wait_event,
now() - xact_start AS xact_age, substring(query,1,50) AS query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY xact_start;
pg_stat_statements：重いクエリの特定（総論 §2）。pg_stat_user_tables：肥大化（n_dead_tup）と autovacuum の効き（MVCC/VACUUM記事）。- レプリケーション遅延：
pg_stat_replicationのreplay_lag。 - 接続使用率：
max_connectionsに対する使用数。 - 周回リスク：
age(datfrozenxid)（MVCC/VACUUM記事 §7）。
6. 守る：最小権限・ネットワーク・暗号化
セキュリティは「クライアントを信じない」から始まります（詳細はセキュリティ堅牢化記事）。要点だけ。
- アプリをスーパーユーザーで動かさない。公式曰くスーパーユーザーは「すべての権限チェックを迂回する」。アプリ専用の最小権限ロール（必要なDMLだけ）を作る。
pg_hba.confは上から最初の一致で認証が決まる（公式）。scram-sha-256を使い、hostsslでTLSを強制し、送信元IP・DB・ユーザーで絞る。trustは厳禁。- パスワードは SCRAM。
password_encryptionの既定はscram-sha-256。MD5 は PG18 で非推奨（CREATE/ALTER ROLEが警告、将来削除予定）。 - クライアントは
sslmode=verify-full。requireは暗号化するが証明書を検証しない＝中間者攻撃を防げない。 - PostgreSQL 18 は OAuth 2.0 認証を追加（
pg_hba.confのoauthメソッド）。
7. 進化させる：止めずにアップグレードする
PostgreSQL のメジャーは毎年リリースされ、各メジャーは約5年でEOL。塩漬けは脆弱性とEOLのリスクです。アップグレードは2択（詳細は論理レプリケーション＆アップグレード記事）。
pg_upgrade（インプレース）：短い停止で済む。PG18 は並列チェック（--jobs）と--swap（ディレクトリ入替で最速）、統計の引き継ぎでさらに短時間化。- 論理レプリケーション（最小停止）：新バージョンのインスタンスへ論理複製し、追いついたら切替。公式曰く「数秒のダウンタイム」で済む。ただしDDL とシーケンスは複製されないため、切替時にシーケンスを手で進める必要があります（この落とし穴は記事で詳述）。
8. マネージド vs セルフホスト：運用負荷で選ぶ
ここまでの「手作業」の多くを、マネージドは代行します。判断軸は**性能やコスト以上に「運用負荷」**です。
| 運用項目 | セルフホスト | マネージド（RDS/Aurora/Cloud SQL 等） |
|---|---|---|
| バックアップ/PITR | archive_command・pg_basebackup を自前構築 | 自動スナップショット＋PITR |
| HA/自動フェイルオーバー | Patroni 等を自前構築（コア機能外） | Multi-AZ で自動 |
| マイナーアップグレード/パッチ | 自分で計画・適用 | メンテナンスウィンドウで実施 |
| 監視 | 自前（Prometheus 等） | CloudWatch 等に統合 |
| チューニングの自由度 | 最大（拡張・OS設定も自由） | 一部制限（許可リスト・パラメータグループ） |
| コスト | サーバー実費（運用人件費は別） | プレミアム（運用込み） |
判断の指針：少人数チーム・運用要員が薄いならマネージド一択に近い。特に自動フェイルオーバーとPITRを自前で正しく作る労力は大きい。逆に、特殊な拡張やOSレベルの制御、極限のコスト最適化が要件ならセルフホスト。「Postgres を任せたい」という発注の多くは、この運用負荷を外注したいというニーズです。
9. 本番運用チェックリスト
リリース前に、この問いに答えられますか。
- 戻せるか：継続的アーカイブ/PITR が有効で、復旧訓練を実施済みか。
- 落ちても止まらないか：スタンバイがあり、フェイルオーバー手順（自動/手動）が確立しているか。
- デプロイで止まらないか：マイグレーションが
lock_timeout＋無停止パターンで書かれているか。 - 詰まらないか：接続プーラーがあり、
max_connectionsに余裕があるか。 - 守れているか：アプリは最小権限ロールか。TLS強制・SCRAM・最小
pg_hbaか。 - 進化できるか：メジャーアップグレードの手順（停止許容時間）が決まっているか。
- 見えているか：重いクエリ・肥大化・レプリ遅延・接続使用率・周回リスクが監視されているか。
10. まとめ
- 本番運用は5つの問い——壊さない／止めない（障害・変更）／詰まらせない／守る／進化させる。
- バックアップは「戻せる」が正義。継続的アーカイブ/PITR ＋復旧訓練。
- コアは自動フェイルオーバーを持たない。外部ツール（Patroni 等）かマネージドで補う。
- 接続はプロセス。サーバーレスはトランザクションモードのプーラー必須。
- 変更も無停止で。
lock_timeout・NOT VALID→VALIDATE・CONCURRENTLY。 - マネージドは運用負荷を外注する手段。少人数なら有力。
- PG18 は非同期I/O・アップグレード高速化（
--swap）・OAuth認証で運用を底上げ。
この運用シリーズでは、各レイヤーを実コードと手順で深掘りします。まずは事故対策の本丸——バックアップ＆PITR と 接続プーリング から。