# PostgreSQL 本番運用ガイド（v18対応）：壊さない・止めない・詰まらせない・守る・進化させるの5原則

> PostgreSQL を本番で安全に運用するための体系ガイド。バックアップとPITR（壊さない）、レプリケーション/HAとゼロダウンタイム変更（止めない）、接続プーリングと監視（詰まらせない）、ロール/TLS/SCRAMのセキュリティ（守る）、メジャーアップグレード（進化させる）までを、公式ドキュメント（v18）に忠実な実コードと運用手順で解説します。マネージド(RDS/Aurora/Cloud SQL)とセルフホストの判断軸も。

- 公開日: 2026-06-26
- 著者: 友田 陽大
- タグ: PostgreSQL, アーキテクチャ設計, パフォーマンス
- URL: https://tomodahinata.com/blog/postgresql-production-operations-guide

## 要点

- 本番運用は5つの問いに答えること：①壊さない（バックアップ/PITR）②止めない（HA・ゼロダウンタイム変更）③詰まらせない（接続プーリング・監視）④守る（最小権限・TLS・SCRAM）⑤進化させる（無停止アップグレード）
- バックアップは『取れている』ではなく『戻せる』が正義。nightly な pg_dump は最大24時間失う。継続的アーカイブ(WAL)なら任意の時点に復旧(PITR)できる
- PostgreSQL コアは自動フェイルオーバーを提供しない（公式明記）。検知・昇格・IP切替は Patroni 等の外部ツールで組む。マネージドはこれを代行してくれる
- 接続は1つにつき1プロセスがforkされる。サーバーレスは直結すると接続ストームで落ちる。トランザクションモードのプーラー(PgBouncer/RDS Proxy)が必須
- 本番のスキーマ変更は ACCESS EXCLUSIVE ロックでSELECTごと止め得る。lock_timeout＋リトライ、NOT VALID→VALIDATE、CONCURRENTLY で無停止に。PG18は非同期I/O・アップグレード高速化(--swap)・OAuth認証を追加

---

データベースの性能を上げる話（[パフォーマンスチューニング総論](/blog/postgresql-performance-tuning-production-guide)）と、データベースを**本番で安全に運用し続ける**話は別物です。後者で問われるのは「速さ」ではなく——**壊れたとき戻せるか、落ちたとき止まらないか、混んだとき詰まらないか、攻撃されたとき守れるか、進化させるとき止めずに済むか**。

この記事は、PostgreSQL を本番で運用するための**全体地図**です。バックアップ・HA・接続・監視・セキュリティ・アップグレードを、**「事故が起きる前提」**で並べ直します。各論は個別記事に譲り、本稿は運用の**意思決定と優先順位**に集中します。受託開発で「Postgres を任せて大丈夫か」を見極める発注者にも、運用を引き継ぐエンジニアにも効く内容です。

> **この記事のルール**：仕様・既定値・PostgreSQL 18 の新機能は **PostgreSQL 18 公式ドキュメント（2026年6月時点）** に基づきます。PgBouncer・RDS 等のベンダー固有事項はその旨を明記します。**マネージドサービスは多くの運用を代行する**ため、ここで述べる手作業の一部は不要になります（その境界も本文で示します）。

---

## 1. 本番運用の5つの問い

運用設計は、次の5つに答えられれば8割完成します。上から「失うと致命的」な順です。

| # | 問い | 失敗すると | 武器 | 深掘り |
| --- | --- | --- | --- | --- |
| 1 | **壊さない** | データ消失（=廃業級） | バックアップ・PITR | [§2](#) / [バックアップ記事](/blog/postgresql-backup-pitr-pg-dump-wal-archiving-guide) |
| 2 | **止めない（障害時）** | ダウンタイム・SPOF | レプリケーション・HA | [HA記事](/blog/postgresql-streaming-replication-high-availability-failover-guide) |
| 3 | **止めない（変更時）** | デプロイで全断 | ゼロダウンタイムDDL | [無停止DDL記事](/blog/postgresql-zero-downtime-schema-migration-lock-safe-ddl-guide) |
| 4 | **詰まらせない** | 接続枯渇・スロー化 | 接続プーリング・監視 | [接続プーリング記事](/blog/postgresql-connection-pooling-pgbouncer-serverless-guide) |
| 5 | **守る** | 情報漏洩・不正アクセス | 最小権限・TLS・SCRAM | [セキュリティ記事](/blog/postgresql-security-hardening-roles-privileges-ssl-scram-guide) |
| + | **進化させる** | 塩漬け・EOL | 無停止アップグレード | [論理レプリケーション記事](/blog/postgresql-logical-replication-cdc-zero-downtime-upgrade-guide) |

---

## 2. 壊さない：バックアップは「戻せる」が正義

最も重い問いから。**バックアップの目的は「取ること」ではなく「戻せること」**です。テストしていない復旧手順は、存在しないのと同じ。

PostgreSQL のバックアップは公式に3方式（詳細は[バックアップ＆PITR記事](/blog/postgresql-backup-pitr-pg-dump-wal-archiving-guide)）。

| 方式 | 何ができる | 限界 |
| --- | --- | --- |
| **論理（`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記事](/blog/postgresql-streaming-replication-high-availability-failover-guide)）。同期/非同期を選べ、リードレプリカで読み取りを逃がせます。

ここで**最重要の事実**（公式が明記）：

> 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記事](/blog/postgresql-zero-downtime-schema-migration-lock-safe-ddl-guide)）：

```sql
-- マイグレーションは「世界を止める前に諦める」。短い 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）が必須**です（詳細・注意点は[接続プーリング記事](/blog/postgresql-connection-pooling-pgbouncer-serverless-guide)）。

### 監視は「症状」で鳴らす

最低限、これは常時見ます。

```sql
-- 詰まりの兆候：長時間 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](/blog/postgresql-performance-tuning-production-guide)）。
- **`pg_stat_user_tables`**：肥大化（`n_dead_tup`）と autovacuum の効き（[MVCC/VACUUM記事](/blog/postgresql-mvcc-transaction-isolation-vacuum-autovacuum-guide)）。
- **レプリケーション遅延**：`pg_stat_replication` の `replay_lag`。
- **接続使用率**：`max_connections` に対する使用数。
- **周回リスク**：`age(datfrozenxid)`（[MVCC/VACUUM記事 §7](/blog/postgresql-mvcc-transaction-isolation-vacuum-autovacuum-guide)）。

---

## 6. 守る：最小権限・ネットワーク・暗号化

セキュリティは「クライアントを信じない」から始まります（詳細は[セキュリティ堅牢化記事](/blog/postgresql-security-hardening-roles-privileges-ssl-scram-guide)）。要点だけ。

- **アプリをスーパーユーザーで動かさない**。公式曰くスーパーユーザーは「**すべての権限チェックを迂回**する」。アプリ専用の**最小権限ロール**（必要な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択（詳細は[論理レプリケーション＆アップグレード記事](/blog/postgresql-logical-replication-cdc-zero-downtime-upgrade-guide)）。

- **`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. 本番運用チェックリスト

リリース前に、この問いに答えられますか。

1. **戻せるか**：継続的アーカイブ/PITR が有効で、**復旧訓練を実施済み**か。
2. **落ちても止まらないか**：スタンバイがあり、フェイルオーバー手順（自動/手動）が確立しているか。
3. **デプロイで止まらないか**：マイグレーションが `lock_timeout`＋無停止パターンで書かれているか。
4. **詰まらないか**：接続プーラーがあり、`max_connections` に余裕があるか。
5. **守れているか**：アプリは最小権限ロールか。TLS強制・SCRAM・最小 `pg_hba` か。
6. **進化できるか**：メジャーアップグレードの手順（停止許容時間）が決まっているか。
7. **見えているか**：重いクエリ・肥大化・レプリ遅延・接続使用率・周回リスクが監視されているか。

---

## 10. まとめ

- 本番運用は**5つの問い**——壊さない／止めない（障害・変更）／詰まらせない／守る／進化させる。
- **バックアップは「戻せる」が正義**。継続的アーカイブ/PITR ＋復旧訓練。
- **コアは自動フェイルオーバーを持たない**。外部ツール（Patroni 等）かマネージドで補う。
- **接続はプロセス**。サーバーレスはトランザクションモードのプーラー必須。
- **変更も無停止で**。`lock_timeout`・`NOT VALID`→`VALIDATE`・`CONCURRENTLY`。
- **マネージドは運用負荷を外注する手段**。少人数なら有力。
- **PG18** は非同期I/O・アップグレード高速化（`--swap`）・OAuth認証で運用を底上げ。

この運用シリーズでは、各レイヤーを実コードと手順で深掘りします。まずは事故対策の本丸——[バックアップ＆PITR](/blog/postgresql-backup-pitr-pg-dump-wal-archiving-guide) と [接続プーリング](/blog/postgresql-connection-pooling-pgbouncer-serverless-guide) から。

---

### 参考（PostgreSQL 18 公式ドキュメント）

- [Chapter 25. Backup and Restore](https://www.postgresql.org/docs/18/backup.html)
- [Chapter 26. High Availability, Load Balancing, and Replication](https://www.postgresql.org/docs/18/high-availability.html)
- [Chapter 29. Logical Replication](https://www.postgresql.org/docs/18/logical-replication.html)
- [Chapter 22. Database Roles](https://www.postgresql.org/docs/18/user-manag.html)
- [pg_upgrade](https://www.postgresql.org/docs/18/pgupgrade.html)
- [PostgreSQL 18 Released!](https://www.postgresql.org/about/news/postgresql-18-released-3142/)