Node.js 使用 node-postgres 时为何要选择连接池 Pool 而非 Client？

一、Pool相比单Client的核心优势与解决的问题 #

• 解决单连接串行查询的阻塞问题：PostgreSQL单条连接同一时间仅能执行1个查询，单Client实例所有查询必须排队串行执行，并发请求下延迟会指数级上升；Pool维护多条连接，可以并行执行多个查询，大幅提升吞吐能力
• 提升容错能力：单Client如果出现连接断开、网络波动的情况，整个服务的数据库访问会直接不可用；Pool会维护多条可用连接，单条连接故障不影响整体服务，且内置自动重连逻辑
• 实现数据库连接数管控：PostgreSQL默认最大连接数仅为100，且连接数过高会大幅降低数据库性能，Pool可以通过配置限制最大连接数，避免服务并发上涨时占用过多数据库连接，影响其他业务
• 内置连接生命周期管理：不需要手动处理连接超时、空闲连接释放、异常连接销毁等逻辑，减少业务代码的维护成本

二、单Node.js服务实例下，单Client与Pool的技术差异 #

• 并发处理能力差异：单Client所有查询串行执行，并发超过1时就会出现查询排队，延迟飙升；Pool多连接并行处理查询，排队仅发生在连接全部被占用时，同等配置下吞吐能力提升数倍
• 故障影响范围差异：单Client单连接故障直接导致全服务数据库访问不可用；Pool单连接故障仅影响当前正在执行的查询，其余连接可正常提供服务
• 资源利用率差异：单Client固定占用1条数据库连接，低并发下资源浪费少，但高并发下完全无法利用数据库的处理能力；Pool可根据配置动态调整活跃连接数，在数据库连接配额和查询性能之间取得平衡
• 维护成本差异：单Client需要手动实现断线重连、超时处理、错误兜底等逻辑，开发维护成本高；Pool内置所有连接维护逻辑，仅需简单配置即可使用

三、Node.js长连接场景下仍需要Pool的原因 #

你之前的认知存在一个核心误区：Node.js维持长连接只能解决「频繁创建销毁连接的开销」，但解决不了PostgreSQL本身的单连接串行执行限制。
Node.js的异步特性只是让你不用等待查询返回就可以处理其他请求，但PostgreSQL的连接本身是单工的，你在单条连接上发送第一个查询后，没收到返回之前是不能发送第二个查询的，所有后续查询都必须排队。如果你的服务有10个并发请求，其中1个是慢查询，单Client场景下剩下9个请求都会被这个慢查询阻塞，而Pool场景下剩余的连接可以正常处理这9个请求，不会出现全局阻塞。
另外如果手动创建多个Client来解决并行问题，你依然需要自己处理连接数管控、连接健康检查、空闲释放等逻辑，这些都是Pool已经封装好的成熟能力，不需要重复造轮子。

内容的提问来源于stack exchange，提问作者Meglio