PgDog拿到融资了，你的PostgreSQL连接池终于有人认真在搞

你要做一个 Web 服务。用户会来访问，你的后端会去数据库查东西。

传统做法：每一个 HTTP 请求，你的代码打开一个数据库连接，查完关闭。新请求来了，再打开。这在几十个并发用户的时候还行。几百个？几千个？数据库进程开始喘了。每个连接都有开销——内存、文件描述符、握手时间。PostgreSQL 对每个连接分配大约 10MB 的内存，就算什么都不做。

一万个并发用户，你的数据库还没开始干活，先吃掉 100GB 内存。

这就是连接池存在的理由：让有限的数据库连接为大量用户请求复用。客户端不直接连数据库，而是先连到一个连接池中间件，中间件管着一组”热连接”，谁要查东西，分配一条空闲的给你，查完还回池子里。

一个老问题的新解法#

连接池不是新概念。PgBouncer、Pgpool-II 这些老牌工具已经在这个领域干了十多年。它们的思路也大致相同——事务级连接池，独立进程部署，配置复杂，调优靠经验。

PgDog 做的不是常规连接池。

它的核心理念是：连接池应该知道你的业务。传统的连接池是个傻转发器——它不知道你在查哪个表，不知道哪些查询慢，不知道哪个客户端在空转。PgDog 可观察性很强，能告诉你每个连接的精确状态，甚至能识别出那些”看似在忙实则卡住”的僵尸连接，帮你自动杀掉。

另一个区别：PgDog 走的是嵌入式代理路线。它可以作为一个 sidecar 跟应用部署在一起，而不是一个需要独立运维的中间件。这听起来像个细节，但在运维层面差别巨大——你不需要专门配一个人管连接池，PgDog 随应用一起启动、一起伸缩，不需要独立的故障处理流程。

为什么投资人现在才认可#

PgDog 最近拿到了一笔融资，金额不大，但信号很明确——基础设施层还有可被颠覆的地方。

过去几年，数据库领域的热钱都流向了 NoSQL、NewSQL、Serverless DB。大家觉得连接池这种”老派的中间件基础设施”已经没有想象力了。问题是，PostgreSQL 的使用量一直在涨，而且涨得很快。所有用 Supabase、Neon、RDS、Aurora 的人最终都会碰到连接数瓶颈。等到你真的有几千个并发用户的时候，PgBouncer 的配置文件会让你怀疑人生。

投资人的逻辑变了：不是找一个全新的东西，而是找一个比老东西好十倍的替代品。PgDog 恰好卡在这个时间点——PostgreSQL 用户基数足够大，现有连接池工具的体验足够差，差到用户愿意为更好的方案付费。

连接池的底层逻辑#

关于连接池，有一个常被忽略的事实：不是所有连接都值得池化。

如果你的应用使用长连接（比如 WebSocket）或者 Serverless 场景（每次调用是一个独立的容器），传统连接池的配置会变成噩梦——你不知道池子里应该放多少连接，因为并发请求数完全不可控。PgDog 在这种场景下采取了动态伸缩策略：它监控实际的请求到达率，自动调整池子大小，而不是让你手动设置 min/max。

当然，它现在还在早期。GitHub 上的星星很多，但生产环境的大规模部署验证还不多。拿了融资之后，团队的首要任务是让更多的 DBA 敢把它放到正式环境里。

不过话说回来，一个好用的连接池能让多少后端工程师少掉几根头发，这本身就是一笔划算的投资。

来源：Hacker News