在撰写关于 Postgres 连接管理文章的十年后,作者指出情况几乎没有改变:Postgres 依然难以应对高连接数,使得 PgBouncer 等工具成为必需品。 对托管 Postgres 服务提供商的调查证实,几乎所有服务商都包含某种形式的连接池。然而,作者认为当前的“售后”式做法(即提供商将 PgBouncer 作为单独且往往复杂的插件进行捆绑)效率低下。这不仅迫使提供商重复构建基础设施,也让用户不得不面对特定的技术限制,例如对 `LISTEN/NOTIFY` 的支持局限。 作者将其与汽车行业进行类比:销售没有集成连接管理的数据库,就像销售没有挡风玻璃的汽车。他主张这应该是一项核心且无缝的功能,类似于 MySQL 或 MongoDB 环境中的体验。尽管关于 Postgres “每个连接一个进程”模型的架构争论长期以来阻碍了进展,但作者认为,转向原生的“一个 URL,一个端口”体验,将是该数据库生态系统中最具影响力的运营改进之一。