Does anyone run Postgres without PgBouncer?

有人不用 PgBouncer 运行 Postgres 吗？

I got a nice shout-out from Ben Dicken over the weekend on an old article I’d written on managing database connections. (This guy is apparently the Mick Jagger of databases, because I can’t remember having gotten so many inbound LinkedIn invitations in one day before.) Something that hit hard is that I wrote this article almost ten years ago. Just as striking is that as I was reading back through it, I realized that despite being a decade old, it’s still pretty much up to date. Postgres is still, shall we say, not great at managing lots of connections, so you want to use local connection pools, short-term checkouts, and a pooler like PgBouncer. It got me wondering: how standard is it to use a pooler, exactly?

上周末，Ben Dicken 在推特上转发了我多年前写的一篇关于管理数据库连接的文章，并给予了很好的评价。（这家伙简直是数据库界的米克·贾格尔，因为我从没记得哪天收到过这么多 LinkedIn 好友申请。）让我感触颇深的是，这篇文章竟然是近十年前写的。同样令人惊讶的是，当我重读它时，我意识到尽管已经过去十年，它依然基本适用。Postgres 在处理大量连接方面依然——怎么说呢——表现不佳，所以你仍然需要使用本地连接池、短期检出以及像 PgBouncer 这样的连接池工具。这让我不禁好奇：使用连接池工具到底有多普遍？

To answer that question, I made a table of all managed Postgres providers with household notoriety and whether they support PgBouncer, something close to PgBouncer, or no connection pooling at all.

为了回答这个问题，我整理了一份表格，列出了所有知名托管 Postgres 服务商，以及它们是否支持 PgBouncer、类似 PgBouncer 的工具，或者根本不提供连接池功能。

Provider	Pooler?	Implementation	Availability / caveat
Aiven	✅	PgBouncer	Startup plans and above
Alibaba RDS	✅	PgBouncer
AWS RDS / Aurora	✅	RDS Proxy	Separate managed proxy service
Azure PG	✅	PgBouncer
Crunchy Bridge	✅	PgBouncer
DigitalOcean	✅	PgBouncer
EDB Postgres AI	✅	PgBouncer
Fly.io	✅	MPG	PgBouncer
Google Cloud SQL	✅	PgBouncer / managed pooling	Requires Enterprise Plus
Heroku	✅	PgBouncer	Some plans only
IBM Cloud	❌	—	Self-managed only
Neon	✅	PgBouncer
OCI (Oracle)	❌	—	No managed pooler
PlanetScale	✅	PgBouncer
Railway	✅	PgBouncer	Added as separate service
Render	✅	PgBouncer	On paid databases
Supabase	✅	PgBouncer or Supavisor	PgBouncer or Supavisor (proprietary pooler) for serverless
Tiger Cloud	✅	PgBouncer

服务商	连接池？	实现方式	可用性/注意事项
Aiven	✅	PgBouncer	Startup 计划及以上
阿里云 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	无服务器架构使用 PgBouncer 或 Supavisor（专有池）
Tiger Cloud	✅	PgBouncer

Not only is PgBouncer support widespread, but we see above that the overwhelming majority of providers bundle it out of the box. I’d go a step further – since neither IBM nor Oracle is a service that any self-respecting person not part of an enterprise sales cycle would actually use, one hundred percent of plausible managed Postgres providers bundle a pooler. If everyone needs it, is it really a non-core function?

PgBouncer 的支持不仅非常广泛，而且从上表可以看出，绝大多数服务商都将其作为开箱即用的功能提供。我甚至想更进一步说——由于 IBM 和 Oracle 并不是任何非企业销售周期内的正常人会真正使用的服务，可以说 100% 的主流托管 Postgres 服务商都捆绑了连接池工具。如果每个人都需要它，它真的还算是一个“非核心”功能吗？

In some ways, it could be argued that this status quo is okay. Users that need a connection pooler have access to one, and can use it to keep prod stable. But there’s undoubtedly a lot of wasted effort here. Every provider has had to come up with their own homegrown mechanism for getting multiple components set up and configured and establish a convention for where to find Postgres versus its bouncer. Every user needs to reference a guide explaining PgBouncer’s limitations (e.g. don’t listen/notify) and read about its pooling modes and tradeoffs.

从某种程度上说，这种现状或许是可以接受的。需要连接池的用户可以获取并使用它来保持生产环境的稳定。但毫无疑问，这里存在大量的重复劳动。每个服务商都必须开发自己的一套机制来设置和配置多个组件，并建立一套约定来区分 Postgres 和连接池的访问方式。每个用户都需要查阅指南来了解 PgBouncer 的局限性（例如不支持 listen/notify），并阅读关于其连接池模式和权衡取舍的内容。

Imagine if you went to your local car dealership and they sold you a car without a windshield. On the way over you’d noticed that 100% of vehicles on the road did in fact have windshields, and for good reason because it turns out to be pretty dangerous to drive without one. Since you were the one that bought the car, it’d be hard to argue that it’s not your responsibility now to outfit it with a windshield before it’s roadworthy, but it’d also be fair to later be pissed off at the dealer for selling a vehicle that can’t just be driven off the lot.

想象一下，如果你去当地的汽车经销商买车，他们卖给你的车竟然没有挡风玻璃。在去店里的路上，你注意到路上 100% 的车都有挡风玻璃，这是有充分理由的，因为没有挡风玻璃开车非常危险。既然车是你买的，你很难推卸在车辆上路前安装挡风玻璃的责任，但如果你事后对经销商卖给你一辆无法直接开走的汽车感到愤怒，那也是合情合理的。

Reintegration

重新整合

What if there was a world where you went to your favorite Postgres provider and you got one database URL, one port, and no extra configuration or caveats to worry about? Your managed provider doesn’t need to add an aftermarket windshield because one came with the car already. We know a place like this can exist because that’s already how things work in MySQL and Mongo-land. There are reasons it doesn’t happen, like reviving the age-old processes versus threads debate, which very few contributors are venerated enough to push for progress on, but given the developer-years’ worth of effort in working around Postgres’ lack of connection pooling, it’s hard to argue this wouldn’t be one of the highest-impact operational improvements possible.

如果有一个世界，当你去你最喜欢的 Postgres 服务商那里时，你只需要一个数据库 URL、一个端口，无需担心任何额外的配置或注意事项，那会怎样？你的托管服务商不需要再加装“售后挡风玻璃”，因为车出厂时就已经自带了。我们知道这样的环境是可能存在的，因为 MySQL 和 MongoDB 的世界里就是这样运作的。虽然这背后有一些原因，比如重新引发关于“进程与线程”的陈年争论，而很少有贡献者有足够的威望去推动这一进展，但考虑到开发者们为了绕过 Postgres 缺乏连接池功能而投入的多年心血，很难否认这将是运营层面最具影响力的改进之一。