なぜコネクションプーリング(PgBouncer)が必要なのか？

Question

Accepted Answer

**コネクションプーリング**は、リクエストごとに新しいコネクションを開く代わりに、少数のデータベースコネクションを多数のクライアントリクエスト間で再利用します。PostgreSQLのコネクションは**高コスト**(各コネクションは大量のメモリを使用する別のプロセス)であるため、負荷環境での性能とスケーラビリティのためにプーリングは必須です。**PgBouncer**は標準的なプーラーです。

## 問題: PostgreSQLのコネクションは高コスト

```text
Each PostgreSQL connection = a separate OS PROCESS, using ~5-10MB of memory.
  ✗ Opening a connection has overhead (process creation, auth, setup)
  ✗ Many connections (e.g. 1000s from a busy app) → huge memory use, contention
  ✗ Postgres has a max_connections limit (often ~100); exceeding it = errors
→ Opening/closing a connection per request, or holding thousands open, doesn't scale.
```

## ソリューション: コネクションプール

```text
A POOL maintains a small set of REUSABLE connections to Postgres.
Application requests BORROW a connection from the pool, use it, and RETURN it.
  ✓ Connections are reused (no per-request open/close overhead)
  ✓ Many app requests share a few DB connections (e.g. 10000 clients → 20 connections)
  ✓ Stays within max_connections, controls resource use → scales
```

## PgBouncer — 標準的な外部プーラー

```text
PgBouncer sits BETWEEN the application and PostgreSQL — lightweight, efficient.
Pooling modes:
  Session   → a connection is assigned for the client's whole session
  Transaction → a connection is held only for the duration of a TRANSACTION (most
               efficient — connections returned between transactions; common choice)
  Statement → per-statement (most aggressive; limited)
→ Transaction pooling maximizes connection reuse for typical web apps.
```

## プーリングが発生する場所

```text
Application-level → many ORM/driver libraries have built-in pools (per app instance)
External pooler (PgBouncer) → a shared pool in front of Postgres (best for many app
  instances / serverless, where per-instance pools would still overwhelm the DB)
→ Serverless especially needs an external pooler (many short-lived instances).
```

## なぜ重要なのか

コネクションプーリングは、PostgreSQLを**規模に応じて**運用するために不可欠な知識です。PostgreSQLのコネクションは独特に高コスト(各プロセスは大量のメモリを使用するOSプロセス)であり、プーリングが必要な理由とその仕組みを理解することは、パフォーマンス的で拡張性の高いデプロイメントのためのシニアレベルの知識です。

根本的な問題は、素朴なアプローチ — リクエストごとにコネクションを開く、または忙しいアプリケーションから数千のコネクションを開いたままにする — はPostgresではスケールしません。コネクションはコスト高(プロセスあたりのメモリ、作成オーバーヘッド)であり、Postgresには`max_connections`制限(通常~100)があり、容易に超過されエラーとリソース枯渇を引き起こします。**コネクションプーリング**はこれを解決するために、少数の再利用可能なコネクションを維持し、多くのアプリケーションリクエストが共有する(借用と返却する) — 数千のクライアントが数十のデータベースコネクションで処理でき、リクエストごとのオーバーヘッドを排除し、制限内に収まります。

**PgBouncer**(標準的な外部プーラー)とその**プーリングモード**を理解する — 特に**トランザクションプーリング**(トランザクション期間中のみコネクションを保持し、再利用を最大化する、Webアプリケーションの一般的な選択) — は重要な実践的知識です。

**プーリングが発生する場所**を知る(インスタンスごとのアプリケーションレベルのプール対、複数インスタンスまたはサーバーレス向けのPgBouncerのような外部プーラー)は重要なアーキテクチャポイントです — **特にサーバーレスは外部プーラーが必要**です。なぜなら多数の短命インスタンスがそうでなければPostgresをコネクション数で圧倒してしまうから(一般的な実際の問題)です。

コネクション管理は負荷下でのスケーラビリティと安定性に直接影響を与え(Postgresのプロセスごとのコネクションモデルはこれを深刻にする)、コネクションプーリング(特にトランザクションプーリングを使用するPgBouncer)は標準的で不可欠なソリューションであるため、コネクションプーリングを理解すること — Postgresがなぜそれを必要とするのか、どのように機能するのか、PgBouncerとそのモード、サーバーレスの考慮 — はPostgresを規模で運用するためのシニアレベルの重要な知識であり、Postgresをスケールできる者とコネクション制限エラーに直面する者を区別する、本番システムにおいて頻繁に重要な関心事です。