Supabase Preview Branch 最容易失控的地方不是单价，而是「PR 关了，测试库还活着」。2026 年 5 月 24 日查看官方文档时，Preview branch 被定义为独立环境，包含 Database、Auth、Storage 等服务；Micro compute 起价是每小时 0.01344 美元，且 Branching Compute 不受 Spend Cap 保护。
所以这篇不讲「要不要用 Supabase」。默认你已经把 Auth、Postgres、Storage 放在 Supabase，正在用 GitHub PR、Vercel Preview 或 Cloudflare Pages Preview 做上线前测试。
把分支当成独立项目看
Supabase Branching 的核心不是数据库 schema 快照，而是一套独立 Supabase 环境。每个分支有自己的 API credentials、数据库、Auth、Storage 和相关服务，适合在不影响 production 的情况下测试配置、schema、Edge Functions 或功能改动。
官方文档还给了一个关键限制：新分支默认不带主项目数据。这对独立开发者是好事，因为生产用户、订单、OAuth 身份和文件不会自动进入测试环境。要准备测试数据，GitHub 集成下更适合用 seed.sql 或 seed file 写一份可重复生成的假数据。
不要把 Preview branch 当成免费的临时库。Supabase 的 Branching usage 文档写得很直接：Preview branch 的使用量按环境计费，Compute、Disk Size、Egress、Storage 都可能进入账单；Branching Compute 会在发票上单独显示，其他用量可能并入项目。
哪些环境该用 preview branch？
先定环境矩阵，再开分支。一个人做 SaaS 时，最常见的错误是 local、preview、staging、production 四层混在一起，最后分不清哪个库可以删。
| 环境 | Supabase 形态 | 生命周期 | 数据策略 | 成本负责人 | 删除触发 |
|---|---|---|---|---|---|
| Local dev | Supabase CLI 本地栈或本地 Postgres | 每天随开发启停 | 假数据，可随时重置 | 开发者本人 | 不需要云端删除 |
| PR preview | Preview branch | 24-72 小时 | seed file，禁止生产数据 | PR 作者 | PR merged / closed 后删除 |
| Staging / QA | Persistent branch | 长期保留，但每周复核 | 脱敏样本或固定假数据 | 产品负责人 | 版本周期结束或不用时降级为 ephemeral |
| Production | Main project | 长期保留 | 真实数据 | 项目 owner | 不删除，只做备份和迁移审查 |
PR preview 只负责回答一个问题：这次迁移、RLS、Edge Function 和前端改动能不能一起跑通。它不该承载长期 QA，也不该拿来做半个月后的演示环境。
Persistent branch 只留给 staging、QA 或长期 development。Supabase 文档明确说 persistent branches 不会因为空闲、PR 合并或 PR 关闭自动暂停或删除。换句话说，你把普通 PR 分支做成 persistent，就等于给自己留了一个长期账单尾巴。
成本怎么算才不会低估？
先只算 compute。Micro branch 每小时 0.01344 美元，官方给过 30 小时约 0.40 美元的例子。按这个单价粗算：
| 场景 | 分支数 | 存活时间 | Compute 粗算 | 读法 |
|---|---|---|---|---|
| 单个 PR 当天测完 | 1 | 8 小时 | $0.11 | 几乎不是问题 |
| 单个 PR 周末没人关 | 1 | 72 小时 | $0.97 | 小钱，但暴露流程问题 |
| 10 个 PR 都开 3 天 | 10 | 72 小时 | $9.68 | 已接近一个 Micro 月成本 |
| 3 个 persistent staging | 3 | 30 天 | 约 $30 | 这是固定月费，不是临时费 |
这张表只算 Branching Compute。真实账单还要看 egress、disk、storage、Edge Functions、Realtime 等用量。Supabase 的 Spend Cap 覆盖部分用量项，但官方 cost control 文档把 Compute、Branching Compute、Read Replica Compute、IPv4、PITR 等列为不覆盖项目。
还有一个容易漏的细节：Compute 按小时计费，项目运行不足一小时也按完整小时算。对 preview branch 来说，频繁开关不一定亏，但「开了就忘」一定会把时间拉长。
PR 分支生命周期怎么定？
给每个 Supabase Preview Branch 写 5 个字段：owner、purpose、expires_at、seed_source、delete_trigger。这比开会讨论「谁记得关」更有效。
推荐规则如下：
| 字段 | 示例 | 不合格写法 |
|---|---|---|
| owner | @li-chen | team |
| purpose | billing-v2-migration-pr-184 | test |
| expires_at | 2026-06-09 18:00 UTC | 空着 |
| seed_source | supabase/seed.sql | copied from prod |
| delete_trigger | PR merged or closed | later |
GitHub PR 模式下，分支名可以跟 PR 号绑定，例如 preview/pr-184-billing-v2。PR 合并前检查迁移、RLS policy、Edge Function secret 和前端环境变量；PR 合并或关闭后，把 Supabase branch 删除或确认自动删除。
Dashboard branching 可以用于快速试 schema 或 Edge Functions。2026 年 5 月比对时，它仍标着 public alpha / beta opt-in，且有一些限制：只能 merge 到 main、preview branch 之间不能互相 merge、migration conflict 要手动处理，pull main 更新时可能覆盖已有 Edge Functions。正式上线流程不要只靠 Dashboard 点点点。
数据库测试环境怎么控？
第一条规则：preview branch 不放生产数据。Supabase 默认 data-less 是保护限制，不是麻烦。seed file 里只放能覆盖业务逻辑的样本：一个免费用户、一个 Pro 用户、一个取消订阅用户、一个即将到期的团队账号、几条异常订单。
第二条规则：schema migration 先走 Git。不要在 Dashboard 里改完表结构再回忆 SQL。独立开发者最稳的路径是：
- 本地写 migration。
- 本地跑 seed。
- 开 GitHub Pull Request。
- 让 Supabase Preview Branch 跑迁移和 seed。
- 前端 preview 指向该 branch 的 API credentials。
- 合并后让 main 执行部署工作流。
- 删除 preview branch，查一次 Usage。
Supabase 的生产部署工作流会走 Clone、Pull、Health、Configure、Migrate、Seed、Deploy 等步骤。Health 会等待 Auth、API、Database、Storage、Realtime 等服务启动并健康，文档写明最长等待 2 分钟。迁移失败时，依赖它的 seed 或 deploy 步骤也会被跳过。
什么时候该保留 persistent branch？
只有三类情况值得保留 persistent branch。
第一类是付费客户演示。你需要一个稳定的 staging URL，客户每周都看，不可能随着某个 PR 关闭而消失。
第二类是多角色 QA。比如你在测团队权限、RLS、订阅状态、Webhook 重试、Storage 上传权限，需要固定数据集反复跑。
第三类是重大迁移窗口。账单系统、租户隔离、OAuth provider 或数据表拆分正在改，preview branch 只能覆盖单个 PR，不足以承载跨 PR 的回归。
除此之外，普通功能分支都用 ephemeral preview。每周固定看一次 Organization Usage，重点看 Branching Compute Hours。如果发现一个 PR 已经关掉但 compute 还在涨，先删分支，再回头补自动化规则。
跨境团队处理 PR preview 时，常常要同时开 GitHub Actions、Cloudflare Pages、Supabase Dashboard 和 Vercel Preview。数据库迁移或账单排查时中途断线，最麻烦的是不知道 migration 到哪一步。需要固定开发环境的团队，可以用海外服务跑 GitHub Actions / Cloudflare 的稳定线路承载这些后台操作。
Supabase Preview Branch 成本控制 不覆盖什么
这里没有假设你已经拿生产项目跑过分支账单，也不把某个账单截图写成普遍价格。本文只按 2026 年 5 月 24 日能公开比对的 Supabase 文档、pricing 和 usage 页面口径写生命周期规则。
Dashboard branching 仍可能变化。分支计费也会随 compute size、disk、egress、storage、Edge Functions 和组织套餐变化。真正上线前，还是要以 Supabase Dashboard 的 Usage、Upcoming Invoice 和当期 pricing 页面为准。