为何 Postgres 离不开 PgBouncer？
Does anyone run Postgres without PgBouncer?
我的一篇关于管理数据库连接的文章在十年后依然适用，这揭示了一个事实：Postgres 在处理大量连接时依然表现不佳。因此，使用本地连接池和 PgBouncer 这样的池化器几乎是行业标准。我调查了主流托管 Postgres 提供商，发现几乎所有服务商都默认捆绑了 PgBouncer 或类似的连接池解决方案。然而，这种普遍依赖外部组件的现状也带来了大量重复配置和文档阅读的工作。如果连接池能像 MySQL 或 MongoDB 那样内置于数据库核心，将极大简化运维流程，这或许是 Postgres 社区最值得投入的高影响力改进方向。
想象一下，如果你去当地汽车经销商买车，他们却卖给你一辆没有挡风玻璃的车。
HN 评论区
15- conradludgate
（我在 Neon 负责 Postgres 代理层的工作）
PgBouncer 完全是可选的，而且并不总是最佳选择。如果你使用的是传统应用（非 Serverless），并且可以在应用层维护连接池，那我建议避开 PgBouncer。
PgBouncer 的优势主要在于应对不规律的客户连接（连接数过多或波动太大）。如果你没有这个问题，直接连 Postgres 就好。
目前我正在探索用替代方案（可能是自研的）来替换 PgBouncer。主要是出于多租户和高可用（HA）的考虑。PgBouncer 对我们来说一直不错，但在多租户环境下的部署方式上，它的局限性比较明显。
- henvic
当然。我的意思是：很多人——如果不是大多数人的话？
就我而言，用 Go 开发时，我一直依赖 http://github.com/jackc/pgx 的连接池，效果相当不错，尤其是配合二进制协议使用时。
- arjie
没有 PgBouncer 我绝对不敢这么干。一旦哪天连接数超标，那就是自找麻烦。问题就在于，你一开始总想着“哦，我在应用层管理连接池就行”，结果后来要么被迫把东西塞进应用里，要么就得为了应用里需要的其他旁路程序去调优连接池。