有人在不使用 PgBouncer 的情况下运行 Postgres 吗？

# 有人不用 PgBouncer 运行 Postgres 吗？ 来源：https://brandur.org/fragments/postgres-without-pgbouncer 周末，我得到了 Ben Dicken 的友情推荐（https://x.com/BenjDicken/status/2086550652776595655），推荐的是我早年写的一篇关于管理数据库连接的文章（https://brandur.org/postgres-connections）。（这位老兄显然是数据库界的 Mick Jagger，因为我不记得之前哪天收到过这么多 LinkedIn 的入站好友邀请。） 让我感触很深的是，这篇文章差不多是*十年前*写的。 同样令人震惊的是，当我重新读这篇文章时，我发现尽管已经过去十年，它基本上仍然没有过时。Postgres 仍然，怎么说呢，不太*擅长*管理大量连接，所以你仍然需要使用本地连接池、短期检出（short-term checkouts）以及像 PgBouncer 这样的连接池工具。 这让我不禁好奇：使用连接池到底是多么标准的事情？为了回答这个问题，我做了一个表格，列出了所有具有知名度的托管 Postgres 提供商，以及它们是否支持 PgBouncer、类似 PgBouncer 的方案，或者根本不支持连接池。 | 提供商 | 连接池？ | 实现 | 可用性 / 注意事项 | |---|---|---|---| | **Aiven** | ✅ | **PgBouncer** | Startup 计划及以上 | | **Alibaba RDS** | ✅ | **PgBouncer** | | | **AWS RDS / Aurora** | ✅ | **RDS Proxy** | 独立的托管代理服务 | | **Azure PG** | ✅ | **PgBouncer** | | | **Crunchy Bridge** | ✅ | **PgBouncer** | | | **DigitalOcean** | ✅ | **PgBouncer** | | | **EDB Postgres AI** | ✅ | **PgBouncer** | | | **Fly.io MPG** | ✅ | **PgBouncer** | | | **Google Cloud SQL** | ✅ | **PgBouncer / 托管连接池** | 需要 Enterprise Plus | | **Heroku** | ✅ | **PgBouncer** | 仅部分计划 | | **IBM Cloud** | ❌ | — | 仅支持自管理 | | **Neon** | ✅ | **PgBouncer** | | | **OCI (Oracle)** | ❌ | — | 无托管连接池 | | **PlanetScale** | ✅ | **PgBouncer** | | | **Railway** | ✅ | **PgBouncer** | 作为单独服务添加 | | **Render** | ✅ | **PgBouncer** | 仅限付费数据库 | | **Supabase** | ✅ | **PgBouncer** 或 **Supavisor** | 用于 Serverless 的 PgBouncer 或 Supavisor（专有连接池） | | **Tiger Cloud** | ✅ | **PgBouncer** | | 不仅 PgBouncer 的支持非常普遍，而且从上表可以看出，绝大多数提供商都将其作为开箱即用功能捆绑提供。我要更进一步：既然 IBM 和 Oracle 都不是任何有自尊心且不处于企业销售流程中的人会真正使用的服务，那么可以说，*百分之百*合理的托管 Postgres 提供商都捆绑了连接池。 ## 如果每个人都需要它，那它真的还是非核心功能吗？ (https://brandur.org/fragments/postgres-without-pgbouncer#non-core) 从某种程度上说，可以说这种现状是可以接受的。需要连接池的用户能够获得一个，并用它来保持生产环境的稳定。 但这里无疑浪费了大量精力。每个提供商都必须想出自己内部开发的机制来安装和配置多个组件，并制定约定来确定在哪里找到 Postgres 与其连接池。每个用户都需要参考指南（https://planetscale.com/docs/postgres/connecting/pgbouncer#when-to-not-use-pgbouncer），了解 PgBouncer 的限制（例如不要使用 listen/notify），并阅读其池化模式和权衡（https://www.pgbouncer.org/config.html#pool_mode）。 想象一下，你去当地车行买车，他们卖给你一辆没有挡风玻璃的车。在去车行的路上，你注意到路上 100% 的车其实都有挡风玻璃，而且这很有道理，因为没有挡风玻璃开车确实相当危险。既然是你买的车，你很难辩称现在上路前给它装上挡风玻璃不是你的责任；但事后对经销商感到恼火——因为他们卖给你的车竟然不能直接开走——也是合理的。 ## 重新整合 (https://brandur.org/fragments/postgres-without-pgbouncer#reintegration) 如果存在这样一个世界会怎样：你前往自己最喜欢的 Postgres 提供商，得到一个数据库 URL、一个端口，而无需担心任何额外配置或注意事项？你的托管提供商无需添加后装挡风玻璃，因为车已经自带了一块。我们知道这样的地方是可能存在的，因为 MySQL 和 Mongo 世界已经是这样运作的了。 这件事没有实现是有原因的，比如重新勾起古老的“进程 vs 线程”之争，而很少有贡献者德高望重到能推动这一进展。但考虑到为了绕过 Postgres 缺乏连接池这一问题已经耗费了无数开发者年（developer-years）的努力，很难说这不是可能实现的最具影响力的运营改进之一。