PgBouncer vs Supavisor vs PgCat：哪个 Postgres 池化器？

PgBouncer 最小化，Supavisor 池在多租户规模上，PgCat 在原始池中添加网络功能。尽管这三者经常在同一页面上逐个术语进行比较，但它们都不是其他两者的直接替代品。

列，按顺序：PgBouncer、Supavisor、PgCat。根据每个项目的官方文件的架构特征，将在您正在部署的版本上进行确认，生态系统在这一点上正在快速发展。

PgBouncer 只做一件事：池 Postgres 连接，没有任何附加功能。这种故意缩小的范围在很大程度上解释了它的长寿以及它在大多数生产中的 Postgres 堆栈中作为基本构建块的采用。

Three pooling modes are available. Session mode opens one server connection per client connection, the most permissive. Transaction mode reuses a server connection between several clients, released at each end of a transaction. Statement mode goes even further, and is rarely used in production. It is the transaction mode that brings the real pooling gain, but it imposes strict rules. Any session state (SETvariables, advisory locks, LISTEN/NOTIFY) does not survive beyond a transaction. We detail these rules and their pitfalls in our dedicated article on the transaction pooling mode of PgBouncer.

历史上，PgBouncer 实例是单进程的，默认情况下使用单个 CPU 核心。在同一端口后面运行多个实例（通过 SO_REUSEPORT）是该项目的最新演变，而不是最初的设计功能。在身份验证方面，PgBouncer 支持可配置的 auth_query，这是一个在每个连接上执行的 SQL 函数，用于动态解析角色的密码。这种机制避免了依赖于预先列出每个用户的静态文件。 Aurabase 正是将这种机制用于其每个项目的角色（第 05 节）。

Supavisor 解决了 PgBouncer 从未设计用于解决如此规模的问题。这涉及从一项服务提供大量不同的租户数据库，而不是每个数据库一个池化器实例。该项目用 Elixir 编写并在 Erlang 虚拟机 (BEAM) 上执行，由 Supabase 在其自己的 GitHub 存储库上开源开发和维护。

原生多租户模型才是真正的结构差异。经典的 PgBouncer 队列需要每个目标基地一个进程（或一组专用连接），而 Supavisor 的工作方式有所不同。它通过 HTTP 管理界面动态注册租户，并将每个传入连接路由到正确的数据库，而无需重新启动服务。正是出于这个原因，Supabase 将自己的云项目从 PgBouncer 迁移到了 Supavisor。每个数据库一个的经典池集群无法扩展到托管数十万个项目的多租户云。

这种架构选择有一个已记录的缺点。项目启动后，在高级案例上与 PgBouncer 的功能对等需要一段时间才能稳定下来。两个例子： LISTEN/NOTIFY的某些行为，以及事务模式下准备语句的精细管理。如果您的应用程序依赖于这些特定行为，请在迁移前检查您的版本。

PgCat 被明确定位为 PgBouncer 的替代品，用 Rust 编写。它向经典池化添加了 PgBouncer 和 Supavisor 本身均未嵌入的网络功能。特别是三个：按分区键的应用程序分片、只读副本之间的负载平衡以及从故障副本自动进行故障转移。该项目诞生于 Instacart，如今由 PostgresML 接管和维护。

具体来说，PgCat 可以扮演两个不同层通常占据的角色：连接池和用于在多个 Postgres 实例之间路由的应用程序代理。已经手动分片数据的团队可以使用 PgCat 简化其代码。对于内部开发的在副本之间分配读取的逻辑也是如此：专用网络层直接取代它。

相反的妥协也存在：PgCat 是一个较年轻的项目，与 PgBouncer 相比，文档和生产反馈的生态系统要小得多。采用其分片和故障转移功能还意味着同意依赖该特定组件的成熟度，而不仅仅是其池容量。

Aurabase 存储库在两个不同的层部署 PgBouncer，均采用事务模式。对于共享队列，Helm 图表在共享数据平面（deploy/helm/aurabase/templates/infra/pgbouncer.yaml，图像 edoburu/pgbouncer）前面定义了专用的 PgBouncer 部署。对于专用实例上的租户，配置程序会生成由 CloudNativePG 本机管理的资源 Pooler （deploy/cnpg/tenant-pooler.yaml，由 k8s_tenant.rs呈现）。两者都不使用 Supavisor 或 PgCat。该代码没有记录此选择之前的显式比较。另一方面，它显示了与 CloudNativePG 生态系统的深度且已经可操作的集成，这与 PgBouncer 是本机池砖的事实一致。

然而，并非所有内容都经过池化器，这是代码本身中记录的有意选择。 PostgREST 仍然与 Postgres 保持实时连接，而不是通过 PgBouncer。 Helm 图表注释明确说明了原因：事务池会破坏其模式重新加载，这取决于 pgrst通道上的 LISTEN 。此机制与客户端之间回收的服务器连接不兼容。出于相同的基本原因，aura-db 管理池（架构、DDL、会话咨询锁）也保持直接连接。非事务范围的 SET search_path 和会话锁在事务模式池化器中无法生存。

# 数据平面 aura-db：通过 PgBouncer，一切都是事务范围的（SET LOCAL）
DATABASE_URL: postgresql://aura_authenticator:...@pgbouncer:5432/aura_db_master

# 池管理（DDL、内省）：直接在 Postgres 上，从不 PgBouncer
# SET search_path 非 LOCAL + 会话锁会破坏事务池
ADMIN_DATABASE_URL: postgresql://aura:...@postgres:5432/aura_db_master

身份验证遵循第 02 节： AUTH_QUERY: SELECT * FROM pgbouncer.user_lookup($1)中描述的 auth_query 模式，没有静态 userlist.txt 文件。这使得每个项目 (project_<uuid>_authenticator) 动态创建的角色可以通过 PgBouncer 进行身份验证，而无需为每个新项目重新部署池化器。

最后一个细节，虽小但很有启发性：Helm 图表默认引脚 edoburu/pgbouncer:v1.24.1-p1 ，而本地 k3d 工作台使用 v1.25.2-p0。这不是一个架构选择，只是两个环境之间稍微缺乏版本同步，代码审查比博客文章捕捉到的细节更快。我们按原样记录它，而不是修饰它。有关此池程序所服务的架构分区的详细信息，请参阅我们关于多租户 RLS 隔离的文章。

如果...选择 PgBouncer

• Postgres 集群通常由 CloudNativePG 或 Kubernetes 管理
• 您想要最经过验证和记录最齐全的池化器
• 每个池化器实例的目标基数适合您

如果……选择督导员

• 同一服务背后有数百或数千个基地
• 需要通过 API 动态注册租户，无需重新部署
• 已经在 Supabase 生态系统中或愿意依赖它

如果...选择 PgCat

• 应用程序共享已经到位或计划在池级别
• 负载平衡和故障转移副本，无需单独的应用程序层
• 能够适应较年轻的项目，但文档比 PgBouncer 少

无论选择什么池化器，它都不会取代 Postgres 本身的大小。池大小和服务器 max_connections 应该一起考虑，而不是一个接一个。太低的 max_connections 前面的宽敞池只会将饱和度从一个级别转移到另一个级别。我们关于 调整 max_connections 的指南详细介绍了在设置池大小之前要应用的大小调整公式。

PgBouncer、Supavisor 和 PgCat 解决同一问题的三个变体，而不是同一工具的三个版本。当您的平台已经依赖 Kubernetes 和 CloudNativePG，或者您只是想要文档最多的池化器时，PgBouncer 仍然是最安全的选择。 Supavisor 的相关性超过了通过同一服务提供服务的一定数量的基地。如果您错过了网络级别的分片和副本故障转移，并且您接受了较年轻项目的成熟度，那么 PgCat 值得绕道而行。

Aurabase 代码显示了一致的而非中立的选择：交易模式下的 PgBouncer，有两个级别：共享队列和每个专用租户的 CNPG 池化器。对于 PostgREST 和模式管理，仍然存在两个已记录的例外情况。如果您想看到这个项目的实际运作而不是纸面上的情况，我们的 性能 页面记录了相关的测量方法。