PostgreSQL 社区是时候考虑内置连接池了！

为什么我们默认了 PostgreSQL 必须外挂一层代理才能用？为什么连接池不能是数据库本身就有的功能？

目录

十年前，PostgreSQL 不擅长处理高并发连接，PgBouncer 是生产环境的标配； 十年后，PostgreSQL 还是不擅长处理高并发连接，PgBouncer 依然是生产环境的标配。

一个悬而未决十年的问题，一个全行业都在默默 “打补丁” 的功能，是时候摆到台面上讨论了：PostgreSQL 内核，该不该原生内置连接池？

全行业的默契：没有连接池，别想上线

为了验证连接池到底是不是 “刚需”，经过统计全球 20 家主流 PostgreSQL 托管服务商的配置，发现结果一目了然：

剔除两家偏向传统企业的服务商后，所有主流云厂商 100% 标配了连接池能力，其中绝大多数直接采用了 PgBouncer。 换句话说：在真实的生产世界里，根本不存在 “不带连接池的 PostgreSQL”。用户买到的、用到的，永远是 “PostgreSQL + PgBouncer” 的组合体。

荒谬的现状：人人都要，人人都要自己装

既然所有人都需要，那它为什么不能是数据库本身的功能？

眼下的生态现状，是全社会的重复投入：

• 厂商侧：每一家云服务商都要独立做 PgBouncer 的集成、打包、配置调优、监控适配，各自制定部署规范和使用说明，本质是同一件事重复做二十遍；
• 用户侧：每一个 DBA 和后端开发者，都要专门学习 PgBouncer 的工作模式、参数权衡、功能边界（比如不支持 LISTEN/NOTIFY），踩过无数坑才能稳定用好；
• 运维侧：每套生产架构都要多维护一层代理组件，多一个故障点，多一份性能开销，多一套监控告警和容灾预案。

打一个形象的比方：这就像你去买车，新车出厂居然没有挡风玻璃。销售理直气壮地说：“大家都自己装啊，门口汽配城就有，装完就能开。” 你确实能装，装完也确实能开，但你永远会觉得哪里不对 ——这本该是原厂就该配齐的东西。

是时候把连接池 “还给” 内核了

放眼整个数据库行业，内置连接池从来不是什么新鲜事。 MySQL、MongoDB 等主流产品早就在内核层面实现了连接池能力。用户拿到一个实例、一个地址、一个端口，开箱即用，不用额外部署代理，不用学习第三方组件，更不用为连接数突增手忙脚乱。

PostgreSQL 并非做不到，而是长期受困于 “进程模型 vs 线程模型” 的历史技术路线之争，内核层面的改进步履维艰。 但我们不妨算一笔账：过去十几年间，整个 PostgreSQL 生态里，所有厂商投入的研发人力、所有用户付出的学习成本、所有运维踩过的坑，这些 “为连接数问题付出的代价” 加起来，早已是一个天文数字。

如果能在内核中内置生产级连接池，这会是 PostgreSQL 有史以来投入产出比最高的体验改进之一：

• 云厂商无需再各自维护 PgBouncer 集成方案，生态重复建设大幅减少；
• 新手学习曲线大幅降低，不用刚入门就被 “连接池 / 事务池 / 语句池” 劝退；
• 业务架构少一层代理跳转，性能损耗更低，故障链路更短，稳定性再上台阶。

写在最后

当然，内核级连接池的落地会涉及大量技术权衡与历史包袱，不可能一蹴而就。 但当整个行业都在用同一种方式 “给内核打补丁”，当所有使用者默认接受 “数据库必须加一层代理才能用”，信号已经足够清晰：

连接池从来不是什么 “锦上添花的非核心功能”，它是生产环境的刚性需求，是数据库易用性的基石。 PostgreSQL 社区，是时候认真考虑把它内置进内核了。