写时复制分支让每个 PR 和 AI Agent 获得秒级隔离的生产数据副本

数据库测试环境的核心矛盾是：测试越接近生产数据越有意义，但复制一份生产数据越昂贵。Snorkel AI 的解决路径展示了写时复制分支如何将这一矛盾从不可调和变为可忽略。

Snorkel AI 为 AI 团队构建数据开发工具，其生产数据库是一个约 2.5 TB 的 Amazon Aurora PostgreSQL 集群。每个打开的 Pull Request 需要独立的 Kubernetes 命名空间来部署代码并运行完整测试套件。此前为每个 PR 恢复一份生产数据库副本需要约 20 分钟，开发者整天开 PR 时合并队列根本等不起。共享预发库、裁剪后的 fixture 或合成数据都会重新引入它们本应解决的问题：测试互相干扰、模式过期、只有真实数据形状才能复现的缺陷。

Databricks 的 Lakebase 是标准 Postgres 的无服务器数据库，存储与计算分离，支持从任意时间点创建可写分支。关键机制在于分支是写时复制的：创建分支是一个元数据操作，不复制任何数据。新分支与父分支共享存储页，只有该分支修改的页才写入新存储。这意味着从约 1 TB 的生产副本创建分支和从 1 GB 数据库创建分支耗时相同——秒级，而非完整恢复的约 20 分钟。

架构分四步：第一，通过 AWS DMS 持续复制将生产 Aurora 同步到 Lakebase 的主分支，保持主分支与生产约 2 分钟以内的差距，DMS 的 Full LOB 模式携带 10 到 20 MB 的 JSONB 值。第二，PR 打开时 CI 管道调用 Lakebase API 从主分支创建新分支，设置过期时间，将连接信息传入 PR 命名空间，分支在一分钟内就绪。第三，应用在 PR 命名空间中通过标准 Postgres 连接其分支，运行迁移、写入数据、修改模式，不影响生产、主分支或其他 PR。第四，PR 合并或关闭时管道删除分支；若清理步骤未运行，分支在 TTL 到期时自动过期。

成本模型随之改变。每个 PR 分支在约 1 TB 共享基础之上写入约 5 到 10 GB 变更，存储增长取决于分支修改量而非数据库大小。计算按分支独立伸缩，空闲时缩至零——即使配置了 100 个分支，同一时刻只有约 20 到 30 个在服务流量，峰值约 5 查询每秒。TTL 确保分支不会长期持有旧页导致存储膨胀。

同一机制自然延伸到 AI Agent 场景。能写 SQL、运行迁移或修改数据的 Agent 也需要一个安全的隔离环境。每个 Agent 任务获得主分支的一个独立分支，可以读取真实数据、写入、甚至修改模式，而不触及生产或其他 Agent 的工作。分支创建耗时与数据库大小无关，因此为每个任务创建一个分支是可行的。团队可以在将 Agent 的变更应用到生产之前审查其分支上的结果；如果结果不对，删除分支即可，没有需要回滚的内容。

需要保留的边界：这是 Databricks 作为 Lakebase 产品厂商撰写的客户工程博客，性能数字为 Snorkel AI 自报，原文自身在结果部分标注了 [VERIFY p95 measured]，表明 p95 延迟尚待独立测量确认。架构细节（DMS 复制、Okta SSO 与 Service Principal 的身份分离、TTL 策略）绑定于 Lakebase 这一特定产品，其他 Postgres 分支方案是否具备同等特性不在本篇讨论范围。60 到 70 名开发者的采用规模属于单一公司的内部实践。