PgDog 重写连接池，解决 PgBouncer 架构缺陷
推荐指数 47.0 NO. 011 · 2026.07.08
发布2026/07/07Score67Comments9
为什么值得看
PgDog 是新的 Postgres 代理，核心卖点是连接池与查询路由、分片能力集成，而非独立组件。对正在用 PgBouncer 但受限于"事务池模式破坏 prepared statement"等 leaky abstraction 的团队，这是值得关注的替代方案。
编辑判断
PgBouncer 的 UNIX 哲学在微服务时代成了包袱：事务池模式省连接但破坏 prepared statement，会话池模式保功能但不省连接，团队被迫二选一。PgDog 的解法是把连接池和协议解析做在同一层，让 prepared statement 在事务池下也能工作。
但真正的战场不在连接池本身，而在 Supabase 的 Supavisor 已经占了托管服务生态位，PgDog 如果只靠"比 PgBouncer 少一个坑"很难换迁移成本。它更适合自托管 Postgres 且深度用 prepared statement 的 SaaS 团队，或者正在从单体往分片架构迁、需要池化和路由同一套配置的中后期公司。
社区反馈
意见分歧 9 条评论
核心争论：PgDog 功能强大但 NOTIFY 接近事务而非严格事务，是否可接受
相关内容
we moved our django app behind pgbouncer transaction pooling a few days ago and the surprise wasn't SET so much as queryset.iterator(). it relies on server side cursors, which don't survive being pooled, so we had to disable it everywhere and let it fall back to client side. also had to move stateme
> Since connection poolers reuse connections between clients, the connection state of one client “leaks” into the connection state of another. Wow this is very bad. This actually happens in typical Postgres setups?
by definition connection poolers re-use connections so it it can happen with any connection pooling setup, PG or no. in pgbouncer the connection is reset via a customisable command [0] which should reset the connection to a clean state. [0] https://www.pgbouncer.org/config.html#server