Does anyone run Postgres without PgBouncer?
摘要
作者回顾了自己十年前写的数据库连接管理文章，指出其内容至今仍适用：Postgres 不擅长处理大量连接，因此需要本地连接池、短期检出和 PgBouncer 之类的池化器。他随后整理了一张表格，列出主流托管 Postgres 提供商对连接池的支持情况：Aiven、AWS RDS、Azure、Crunchy Bridge、DigitalOcean、Google Cloud SQL、Heroku、Neon、PlanetScale、Railway、Render、Supabase 等绝大多数都内置或提供 PgBouncer（或类似方案），仅 IBM Cloud 和 OCI 不自带托管池化器。作者认为既然所有靠谱的托管商都捆绑了池化器，说明连接池其实是核心功能，当前各提供商各自为政地配置 PgBouncer 造成了大量重复劳动，用户还需了解其限制（如不支持 listen / notify）。他设想理想情况是像 MySQL 和 MongoDB 那样，Postgres 原生内置连接池，用户只需一个 URL、一个端口，无需额外配置，并认为这是最具影响力的运维改进之一，但受制于进程与线程之争等历史原因难以推进。
荐读理由
这份主流托管商对照表直接告诉你：选任何一家靠谱的 Postgres 服务都自带连接池，不用自己折腾 PgBouncer，省下配置和踩坑时间
原文
Does anyone run Postgres without PgBouncer?
Fragment
🔗 Does anyone run Postgres without PgBouncer?
Published
Aug 12, 2026
I'm on X/Twitter at @brandur.
Aug 12, 2026
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? 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.
| 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 |
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?
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.
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.
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.
Did I make a mistake? Please consider sending a pull request.
这条对你有帮助吗？