Serverless场景下何时用pg Client替代max:1配置的Pool？

我在Stack Overflow上看到很多解释node-postgres（pg）中Client与Pool类差异的回答，核心都提到用Pool实现多连接高效利用，但没人说明必须或更适合使用Client的场景。

目前我用Kysely查询构建器开发Serverless方案，Kysely的pg适配器只支持Pool类，我把它配置成单连接（max:1）用于Vercel+Supabase的Serverless环境，运行正常。现在想搞清楚两个问题：

1. 在node-postgres中，什么时候必须用Client而不能用Pool？
2. 在Serverless场景下，使用max:1配置的Pool会不会有问题？

一、必须/更适合使用Client的场景 #

• 长事务或会话级操作场景：如果要执行一系列依赖同一会话状态的操作（比如创建临时表、设置会话级变量、连续的事务步骤），必须使用Client。因为Pool会在查询完成后回收连接，无法保证后续查询复用同一个连接，之前设置的会话状态会直接丢失。比如用Pool创建临时表后，下一次查询可能拿到另一个连接，根本访问不到这个临时表。
• 需要手动控制连接生命周期的场景：比如要长时间持有连接做批量数据处理，或者需要精确控制连接的打开、关闭时机，Client比Pool更直接，无需考虑连接池的自动回收逻辑。
• 资源极度受限的环境：比如某些嵌入式或轻量运行环境，连Pool的初始化开销都承担不起，直接使用单个Client会更轻量。

二、Serverless场景下max:1配置Pool的问题 #

在Vercel+Supabase这类Serverless环境中，使用max:1的Pool基本没有问题，甚至是适配场景的推荐配置，原因如下：

• 匹配Serverless函数特性：每个Serverless函数实例都是短生命周期的，处理完请求就销毁，不会长时间持有连接。max:1刚好对应单实例单请求的模式，不会出现连接竞争。
• 避免连接泄漏：Pool自带连接回收机制，即使函数意外退出，Pool的销毁逻辑会自动释放连接，比手动管理Client的连接关闭更安全。
• 适配Kysely框架要求：既然Kysely仅支持Pool，max:1既满足框架适配需求，又符合Serverless的资源模型，不会产生额外性能损耗。

唯一需要注意的是：如果你的函数在单个请求中需要并行执行多个查询，max:1的Pool会让这些查询串行执行，可能略微影响响应速度。但Serverless请求大多是单逻辑流，这种场景很少见。如果确实有并行需求，可以临时调高max值，但要注意Supabase的连接数配额，避免超出实例允许的连接上限。

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