Supapool：给每个 AI Agent 开一个 1 秒就绪的临时 Supabase，以及它的停服启示

Supapool 是一个被 AI Agent 潮流催生出来的基础设施：当多个编码 Agent 并行干活时，每个都需要一个独立、干净的 Supabase 数据库，否则它们会在运行中互相清空对方的库。Supapool 的做法是——用一行 CLI 命令，临时给你租一个完整隔离的 Supabase 实例（真实 Postgres + Auth + S3 兼容存储），用完即抛。

但本文必须先讲一个最关键的事实：打开 supapool.io，最顶上的黄色横幅写着”Supapool is sunsetting. We’re winding the service down to focus on a new product.”——这个服务正在停服，团队要转去做新产品。这让它从”一个你应该立刻接入的工具”，变成了”一个值得解剖的现象样本”。

一、背景动机：并行 Agent 需要临时数据库

传统上，要给开发/测试一个独立 Supabase 环境，用的是 Supabase 官方的”数据库分支（branching）“。Koala 点评指出问题：分支创建慢、按生产实例计费。而 Agent 并行开发的场景里，你需要的不是一个长期维护的分支，而是一个几分钟内创建、用完即扔的临时实例。

Supapool 的定位就是”快和便宜”：实例是 ephemeral 的，跑在离 Agent 工作地点近的位置（colocated），而不是固定在某个家用区域。

二、是什么：CLI 包一层命令，租一个临时实例

用法极简（官网原文）：

npx @supapool/cli run -- npm run dev

run 命令做了这几件事：租一个干净实例 → 按文件名顺序跑完 supabase/migrations 目录下所有 .sql 迁移 → 把实例凭证注入环境变量后启动你的命令 → 命令运行期间持续续期租约 → 命令退出时释放实例。它不会修改你仓库里的任何环境文件。

它也提供库模式：withInstance(async (instance) => {...})，回调抛异常也会保证释放实例；底层导出 acquire / renew / release / startRenewer 原语供自行管理租约边界。

三、技术机制：租约 + 自动续期 + 全框架变量注入

• 真实栈，非 mock：真实 Postgres、Auth、S3 兼容存储，迁移与数据库操作直接打在真实隔离的 Supabase 上；
• 租约 TTL：每个实例是一个带 TTL 的租约，默认 30 分钟；命令运行时 CLI 每 5 分钟自动续期；命令退出或进程死掉、续期停止，租约过期、槽位清空回池。实例里存的东西释放后不保留——“treat every run as disposable”；
• 注入的环境变量：标准 SUPABASE_URL、SUPABASE_ANON_KEY、SUPABASE_SERVICE_ROLE_KEY、DATABASE_URL；并镜像到 Next.js、Vite、Astro、Svelte、Expo、CRA、Gatsby、Nuxt 的 public/secret 前缀名，以及 Prisma 与 PG* 连接变量。密钥从不写进浏览器可见的 public 变量；
• 纯 CLI，无 dashboard：账号、用量、成本都通过 CLI 与 API 暴露，“built for agent ergonomics”，方便直接管道进公司内部系统；
• CI 友好：本地登录一次，把 ~/.config/supapool/config.json 里的 key 配成 CI secret（SUPAPOOL_API_KEY=sp_live_...）即可；
• Beta 期免费。

四、关键事实表

五、口径偏差与必须正视的局限

1. 服务正在停服——这是最大的”口径”。官网横幅明确说 winding down、转做新产品。这意味着：即便它的设计很精妙，现在也不是一个适合把 CI/开发流程押上去的长期方案。选型前必须接受”它随时可能关”。
2. “1 秒就绪”是官网宣传值，未给出在不同负载/网络下的实测分布；属于”官方称”。
3. 用完即抛意味着零持久化。所有数据在租约释放后清空，它只适合短暂的开发/测试，不能存任何需要保留的东西。
4. 依赖第三方托管服务。实例由 Supapool 运营方提供，实例 colocation、可用性、数据安全都不在你手里；对数据敏感的团队要评估把测试库凭证交给它的风险。
5. 与 Supabase 官方分支是互补而非替代。Koala 点评也说：它主打造得快、用完即抛，不替代长期分支。如果你需要长期分支环境，Supabase 官方分支仍有其位置。
6. Beta + 停服双重早期信号。免费 Beta 期间功能与稳定性本就未定型，又叠加停服，生产风险高。

六、适用 / 不适用场景

适合（在它还活着时）：

• 多个编码 Agent 并行跑、需要各自干净数据库的本地/CI 测试；
• 想对真实 Supabase 栈（而非 mock）跑迁移与数据库操作；
• 想要无 dashboard、可管道化进自动化流程的 CLI 工具。

不适用：

• 需要长期保留数据或长期分支环境——它用完即抛；
• 想要一个稳定、长期可用的托管服务——它正在停服；
• 数据不能交给第三方的严格合规场景。

七、客观分析：它留下了什么

价值（设计层面）： 把”临时数据库实例”抽象成一个带 TTL、自动续期、自动迁移、全框架变量注入的租约，且纯 CLI、为 Agent 人体工学设计——这是非常贴合 Agent 时代的基础设施形态。

现实（产品层面）： 它正在停服。这本身就是一个信号：被 Agent 催生的基础设施赛道极度拥挤且短命，一个设计精巧的工具可能在 Beta 期就因为商业方向调整而关停。对用户而言，这类 ephemeral 工具的正确用法是”借它的思路”，而不是”深度绑定它的服务”——真正可持续的做法，是把这种”临时隔离环境”能力在自有基础设施上复现（比如用 Supabase 官方分支、或本地 Docker 起临时 Postgres）。

它意味着什么： Supapool 是一面镜子。它证明了”并行 Agent 需要一次性数据库”是真需求；它的停服则提醒我们，在 Agent 基础设施这片蛮荒地上，工具的生命周期可能比它解决的问题还短。看懂它的机制，比接入它的服务更有长期价值。

参考来源

• Supapool 官网
• Koala 项目库条目：Supapool