Hacker News 热议：PgBouncer 完全是可选的！

由 John Doe 九月 4, 2026

Hacker News 最近在热议：有人在不使用 PgBouncer 的情况下运行 Postgres 吗？

核心共识：PgBouncer 并非银弹，取决于架构

Hacker News 评论区的核心共识是：PgBouncer 完全是可选的。 盲目引入 PgBouncer 只会徒增架构的复杂性（“如果你不需要它，你就只是白白增加了复杂性”）。是否使用它，完全取决于你的连接特征，而不是业务规模。

大量资深开发者分享了他们在非平凡（non-trivial）的生产环境中，不使用 PgBouncer 的场景：

传统后端与长驻应用（Classical Apps）：如果你的后端是长驻进程（如 Java Spring Boot 服务器、常驻 Node.js/Python 进程），且能在应用内部（例如使用 HikariCP 等）维持固定的连接池，那么完全不需要 PgBouncer，直接连接 PostgreSQL 即可。
并发用户少但数据量大的系统：例如许多 B2B 内部服务、企业级后台。有开发者分享了自身 10-20 TB 数据量、300 事务/秒的系统，仅靠 VIP (keepalived) 即可良好运转。
数据管道与批处理任务：在使用 Postgres 进行类似 Map-Reduce 的数据管道计算，或离线批处理任务时，可以直接根据 CPU 核心数建立对应数量的直连。
重度长事务场景：PgBouncer 对“运行时间极长的事务”束手无策。它只能交错处理短事务，遇到长事务时它也只能让其他请求排队等待。

评论指出，PgBouncer 的核心解决场景是“不规则的客户端连接（极高的并发量或极高的连接销毁/建立频率）”：

Serverless 架构：在 AWS Lambda 或 Vercel 等无服务器平台上，成百上千的并发 Worker 无法共享内存中的连接池。每次调用都新建连接会导致“连接风暴”（Connection Storm），轻易压垮 Postgres 的原生进程隔离机制。
重度依赖单进程/单线程的语言框架：历史上类似 PHP/FastCGI 或没有做好应用层连接池配置的 Python/Ruby 应用，扩展大量 Web worker 必然导致数据库连接数超载，此时需要 PgBouncer 居中调度。

来自 Serverless Postgres 厂商 Neon 的工程师（conradludgate）亲自下场分享了硬核技术细节：

单线程瓶颈：PgBouncer 作为单线程服务，在部署于低主频的典型服务器 CPU 上，且面临重度客户端并发时，自身就会成为性能瓶颈。
多租户与 HA 管理噩梦：在 Neon 这种每小时有成千上万个数据库被创建和销毁、存在数百万个数据库的极端多租户环境中，管理 PgBouncer 的配置和共享池逻辑极其困难。
架构视角的反思：有开发者指出，很多时候 PgBouncer 只是解决上游架构设计不良的“创可贴（duct tape）”。如果系统设计为在 Web 接入层排队等待，而不是让每个线程都死死占住一个后端去等数据库连接，就能在不用 PgBouncer 的情况下实现高并发。

评论区有不少声音批评原作者的态度和论点：

商业云服务的偏见：原作者在文中傲慢地声称“任何有自尊心的人都不会使用 IBM 或 Oracle 的云”。评论区反驳称，这显示了作者自大的局限性（例如支持 Z Mainframes 必须用 IBM）。
Oracle 工程师的“降维打击”：一位自称 Oracle 数据库团队的工程师指出原文逻辑极其讽刺。原作者抱怨 Postgres 十年来没有解决“单 URL 弹性扩缩容连接”的问题，但实际上 Oracle DB 原生就内置了服务端连接池和客户端负载平衡，完美解决了作者所有的痛点，却被作者以偏见排除在外。
License 审计的恐惧：针对上述 Oracle 工程师的回复，其他开发者务实地回应：大家之所以首选 Postgres 哪怕去折腾连接池，是因为商业数据库（如 Oracle/Informix）高昂的授权费和极具攻击性的合规审计（Licensing Audits）足以摧毁一家小公司。

针对部分不需要高并发的场景，有人提问 “为何不用更简单的 SQLite？”。坚守 Postgres 的开发者给出了三大理由：