为什么您需要连接池 (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 连接成本特别高（每个都是一个单独的操作系统进程，占用大量内存），所以理解为什么需要池化以及它如何工作是高级工程师对于高性能、可扩展部署的重要知识。

核心问题在于简单的方法——为每个请求打开连接，或从繁忙应用程序保持数千个连接——无法与 Postgres 一起扩展：连接成本高（每个进程的内存、创建开销），而 Postgres 有 `max_connections` 限制（通常约 100 个）很容易被超过，导致错误和资源耗尽。**连接池**通过维护一小组可重用连接解决此问题，这些连接由许多应用程序请求共享（借用和归还）——因此数千个客户端可以由几十个数据库连接提供服务，消除了每个请求的开销，并保持在限制范围内。

理解 **PgBouncer**（标准外部连接池）及其**池化模式**——特别是 **transaction pooling**（仅在事务期间保持连接，最大化重用，这是 Web 应用程序的常见选择）——是重要的实用知识。

了解**池化发生的位置**（每个实例的应用级池，与许多实例或无服务器的外部池（如 PgBouncer）相对）是一个关键的架构考虑——**无服务器特别需要外部池**，因为许多短生命周期的实例会因其他方式使 Postgres 连接过载（一个常见的现实问题）。

由于连接管理直接影响负载下的可扩展性和稳定性（Postgres 的每进程连接模型使此特别关键），而且池化（尤其是带事务池的 PgBouncer）是标准的、必要的解决方案，理解连接池——Postgres 为什么需要它、它如何工作、PgBouncer 及其模式，以及无服务器考虑——是大规模运行 PostgreSQL 的重要高级知识，这对生产系统往往是至关重要的考虑，区分那些能够扩展 Postgres 的人和那些遭遇连接限制失败的人。