赋能演化式数据库开发：使用 Lakebase 实现数据库分支

**本系列存在的原因**

《进化式数据库设计》中阐述的方法论，以及在《数据库重构：进化式数据库设计》中落地实施的实践，已有二十年历史。其中提出的七项核心实践、70余种命名明确的重构模式，以及相应的迁移机制——均已形成完整文档，经过同行评审，并被广泛讲授。

该方法论于2010年随《持续交付》（第12章：数据管理）正式融入CI/CD体系。数据库迁移由此成为部署流水线中的一等公民，将“数据库变更即代码”的理念推广至整个CI/CD运动。然而，持续交付并未解决流水线级隔离问题：尽管流水线可执行迁移操作，但仍需指向一个目标数据库，而该目标数据库通常是共享的。实践#4——“每位开发者都拥有自己的数据库实例”——对大多数团队而言仍停留在理想层面，因为真正具备生产环境规模、专属于每位开发者的数据库实例，往往耗费大量时间、资金与DBA人力。

为弥补这一缺口而兴起的补偿性方案（如模拟对象、共享预发布环境、内存型数据库替代品、DBA工单队列等），逐渐演变为默认的基础方法论，而非经过深思熟虑的设计选择。

2026年，写时复制（copy-on-write）数据库分支功能正式登陆Databricks Lakebase。现在，对一个TB级生产数据库进行一次零存储开销、仅需一秒的分支操作，已成为O(1)复杂度的操作。长期制约实践#4落地的核心约束已被彻底解除。

本系列将探讨当这一约束解除后所发生的变化：方法论本身依然稳固不变；真正改变的是首次得以实现的新实践、自动达成的团队级治理机制、DBA角色的演进，以及人类与AI代理共同依赖的新技术基底。

**认识 Jen**

Jen 是《进化式数据库设计》一文中设定的开发者角色。在那篇文章中，她将一项数据库重构任务——将 inventory_code 字段拆分为 location_code、batch_number 和 serial_number——作为常规用户故事完成，生动展示了DBA与开发者如何协作、Schema如何小步迭代演进，以及迁移脚本如何安全承载变更。

本系列承接Jen二十年后的旅程。她所遵循的方法论与2003年时完全一致。真正变化的是其工作流之下的技术基底：写时复制数据库分支能力，使她多年来研读的那些实践，如今可在生产规模下切实落地。本系列共三部分，Jen始终是同一个人，但分别从三个尺度展开：她的日常工作（第一部分）、她的新工作手册（第二部分）与她的团队协作（第三部分）。

第一部分：Jen的故事——一个功能，一次数据库变更

为理解其运作方式，我们跟随一位名为Jen的开发者，完整走一遍她实现如下任务的过程：用户应能在库存系统中查看、搜索并更新某产品的所在地、批次号与序列号。

下文将详述Jen为完成此任务所需经历的各个步骤，并对比她在传统数据库环境与使用Lakebase（支持低成本数据库分支）环境下的工作流程差异。

Jen开始着手她的功能任务

Jen接手了一项看似简单的功能需求：产品团队希望用户在添加库存时即可录入物品的所在地、批次号与序列号，并在后续应用流程中复用这些信息。从外部视角看，改动似乎微不足道：只需在界面上新增字段、保存值、在库存页面展示该信息，或许再用于下游决策逻辑。

对Jen而言，应用层改动清晰明了：她清楚表单所在位置、处理请求的服务模块，也看得出模型对象需新增哪些属性。但一旦将变更路径全程追溯到底层，她立刻意识到真正的依赖所在——数据库也必须同步变更。

需要新增若干列；现有生产环境中的数据必须保留且语义正确；应用程序须能安全兼容新旧数据；她还需补充测试，以验证新字段确实被正确存储、读取与展示。原本看似简单的功能，如今已演变为一次需协调应用与数据库的联合变更，并额外承担起确保既有生产Schema与数据平滑迁移到新Schema的责任。

共享数据库

Jen 为即将开展的工作创建了一个代码分支。由于团队使用共享数据库进行开发，她立即开始思考自己将在数据库层引入的各类变更可能对其他共享数据库用户造成的影响，并着手规划如何确保这些变更对他人是安全的：她能否在本地运行应用变更，并执行单元测试与集成测试？每种方案都有其成本：她可以等待；可以请求团队协调；也可以通过 Docker 启动一个本地 PostgreSQL 实例，用一周前的 pg_dump 快照初始化数据，并寄希望于其间差异无关紧要；或者退而求其次，在容器中运行本地数据库，或使用 H2、SQLite 等内存型数据库——它们虽运行迅速，但采用不同的 SQL 方言，导致测试在本地通过，却在真实 PostgreSQL 环境中暴露出未知错误。她甚至能测试自己的表结构与数据迁移脚本吗？这种“怕破坏他人工作”的顾虑拖慢了她的节奏，同时也限制了她对多种功能实现方案的探索尝试。

图 1：展示一个共享数据库，各类用户同时访问开发数据库。

在共享数据库环境中，一名开发者可能正在测试业务逻辑变更，另一名正在调试数据迁移脚本，还有人创建了 Jen 并不理解的测试数据。若 Jen 将其表结构变更直接应用到共享数据库，可能会破坏他人的工作；若他人在她测试期间修改了表结构，她的测试结果将不再可靠；若她添加测试数据，也可能干扰其他开发者的假设前提。

Jen 可以等到共享数据库空闲时再操作——这虽可避免冲突，却将一个小功能演变为排期难题，造成生产力损失。她也可手动与其他开发者协调：“你现在在用 dev 环境吗？”“我能跑个迁移吗？”“请未来一小时内别重置数据。”——类似接力赛中的交接棒，短期内可行，但难以扩展，尤其当团队成员分布异地或处于不同时区时。

Jen 还考虑过另一种方案：使用本地内存数据库。但她清楚，这种配置无法反映团队其余成员所用数据库的真实状态，这意味着她无法对解决方案建立充分信心——变更可能在本地运行正常，却在更高环境（如预发布或生产环境）面对真实数据与表结构时失败。

Jen 面临的核心问题实则是反馈延迟：她可以做出变更，但验证其是否有效却缺乏快速、真实且可靠的反馈机制；缺少这种反馈，数据库变更便成为团队谨慎对待的高风险操作，最终往往仅选择首个可行方案，放弃多方案实验与优化，从而导致次优解、效率下降及开发者不满。

个人数据库分支

借助 Lakebase，Jen 获得了为个人用途创建数据库分支的能力，这一能力彻底改变了她的工作方式。

她不再需要等待共享开发数据库空闲，而是直接通过命令 databricks postgres create-branch 为其功能创建数据库分支，或借助 VS Code / Cursor 插件 完成操作。此举立刻重塑了工作流程：她无需再向团队申请“安静窗口”；无需与其他开发者协商谁可在何时运行哪项迁移；也无需费心保护自己尚未完成的变更免受他人未完成变更的干扰。她拥有了专属的隔离数据库空间，该空间基于与生产环境一致的数据库类型构建。

图 2：团队每位成员均可获得专属数据库，必要时还可拥有多个数据库。

该分支为 Jen 提供了所需数据库状态的快速副本：她现在使用的 Postgres 引擎、表结构、治理策略以及数据形态，均与直接查询生产环境所得一致。唯一区别在于：此分支可自由修改、丢弃或重建，且不会影响任何其他任务。她并非在行为与生产环境不同的简化本地数据库上测试，而是在与生产环境完全一致的数据库类型上工作——包括相同的表结构规则、约束条件、索引、参考数据及迁移历史，这些要素共同决定了数据库变更在真实世界中是成功还是失败。这种真实性至关重要，因为许多数据库问题并不会在孤立的单元测试中暴露，而只会在新迁移脚本遭遇既有结构、既有数据、既有假设及既有应用行为时显现。

如今，Jen 可将数据库变更视为设计环节的一部分，而非仅作为部署步骤。她可先尝试最直观的方案：新增列、设定默认逻辑以拆分现有字段、编写数据库迁移脚本、更新应用并运行测试。随后，她能提出更深入的问题：该迁移脚本能否应对生产环境的数据量？生产数据质量是否符合脚本预期？数据迁移脚本是否掩盖了缺失的业务信息？偏好设置应建模为简单列、查找表，还是独立的 item_information 表（因后续很可能需补充更多字段）？查询模式是否需要索引支持？该设计是否会简化或阻碍下游报表生成？在旧有工作流中，这些问题常被压缩忽略，原因正是数据库变更成本高昂。

图 3：Jen 在任务处理中的工作流，具备数据库分支能力

在分支工作流中，Jen 可以在功能仍在演进时就对其进行探索。DBA 可与她结对协作，指导她理解生产环境中的细节与数据量问题，从而在方案设计阶段就提供宝贵输入，而非仅作为事后的审查者。

让应用与数据库同步变更

Jen 编写迁移脚本。无论她的团队使用的是 Flyway、Liquibase、Alembic、Knex 还是 Prisma，该脚本均存放在代码仓库中，与应用变更并列存放。模式（schema）与数据迁移随代码一同流转。

（这正是拆分列重构——收录于《数据库重构》一书的约 70 种模式之一；该书将七项实践制度化，详见：Refactoring Databases。）

她通过 flyway migrate 将迁移应用到自己的分支上。该工具在真实结构的数据集上运行耗时不到一秒。她更新仓库代码以读写三个新列，并运行测试套件。测试直接针对真实的 PostgreSQL 执行，无需 mock 或内存替代方案，全部通过。

若她希望从头开始尝试另一种方案，只需丢弃当前分支，从生产环境新建一个干净分支即可——再花一秒。无需清理工单，也无需 DBA 参与。

同一位 Jen，同样的重构操作。变化的是其能力。

更快失败的空间

实验能力至关重要。渐进式设计与开发不仅意味着快速完成预设清单，更在于随着工作逐步具体化而持续学习。Jen 可能发现：首个模式设计虽可行，却导致应用逻辑笨拙；第二个设计更简洁，但使现有记录的迁移变得复杂；某个微小的规范化决策如今做出，未来变更将更轻松；她最初编写的迁移脚本中，SUBSTRING 索引偏移了一位；破坏性 DROP COLUMN 操作在确认新列已正确填充前便已执行。正因她拥有专属分支，这些发现成本极低：她可应用迁移、运行应用、检查数据、继续推进下一次迁移，或重置分支尝试其他路径。

分支还改变了工作的心理状态。Jen 无需过度谨慎，因为他人不会依赖共享的开发数据库；她不必向团队宣布每一次实验；她也不必立即清理测试数据，以免其他开发者误踩雷区。她的分支是未完成思考的安全空间——可容纳临时表、失败的迁移尝试、别扭的测试数据及半成品设计，而不会给他人制造干扰。

与此同时，隔离并不意味着脱离团队规范。Jen 仍需编写迁移脚本；仍将应用代码与数据库变更保持同步；仍会运行测试；仍预期最终设计接受评审。区别在于：她可在私密环境中快速完成工作的“混乱”部分，再请团队审视打磨后的版本。当她提交 Pull Request 时，讨论焦点可集中于“设计是否合理”，而非“她是否有安全的测试环境”。

这是关键转变：数据库分支为 Jen 提供了快速、真实且隔离的反馈机制——她还可将该分支展示给技术负责人或 DBA 进行评审。快速意味着她可在需要时即时创建环境，而非等待他人配置；真实意味着她测试的数据库行为与生产环境一致；隔离意味着她的实验不会干扰他人。这三项特性共同将数据库变更从瓶颈转变为功能开发的常规环节。

Jen 现在可以同步推进应用与数据库。她的代码分支与数据库分支成为同一任务的两面：一面承载应用变更，另一面为其提供真实的数据库运行环境。她不再被动等待、协调或依赖简化版设置，而是能够自由设计、测试、修订与学习。功能规模依然不大，但数据库已不再是拖慢进度的根源。

提交 Pull Request

Jen 提交应用代码与迁移脚本，并发起 PR。

CI 将复现 Jen 刚刚的操作，但面向整个团队：它创建自己的临时 Lakebase 分支，应用迁移，运行应用测试套件，针对迁移后的模式执行数据库测试，验证迁移本身（是否干净应用、幂等、可逆），并在 PR 中添加 schema-diff 评论，精确列出变更的数据库对象。

评审者现在可在线查看模式变更与其所用代码的对应关系，使其上下文理解从抽象转向具体。

_截图来自__Lakebase SCM Extension__的“分支差异摘要”视图_

审查变更

在旧工作流中，数据库审查的核心问题是：“这会破坏数据库吗？”——由 DBA 把关，因其必须孤立地审视每一项变更，因为任何疏漏都可能引发生产级后果。审查需同步进行，日程常冲突；DBA 的日历变成排队队列，有时甚至因“上市时间”压力而被跳过。

在新工作流中，核心问题是：“这个设计是否正确？” DBA 已经通过 CI 查看过 schema diff，并已见证迁移在真实数据分支上成功执行。Jen 还可主动邀请 DBA 参与讨论，向其展示自己的思路以及她尝试过的其他方案。DBA 可按自身节奏进行评审，而非受限于 Jen 的时间安排。他们能在解决方案开发周期的更早阶段介入评审，从而在数据完整性、索引策略、未来可扩展性或长期可维护性等方面优化方案，而非像过去那样将大量时间耗费在防御性的“守门”环节。

团队将代码与数据库变更一并评审：一个 PR，一次讨论，同一窗口。

信心十足地合并

该迁移已在真实数据分支上完成测试；应用已基于变更后的 schema 成功运行；schema 迁移已完成评审；CI 构建已完整复现相同步骤，并持续保持绿色状态达一小时。

当 Jen 执行合并时，迁移将自动应用于下一环境；同时，CI 环境及 Jen 的数据库与代码分支均被清理。此举确保数据库变更不再成为发布夜的意外风险。

Jen 刚刚所做之事，正是源自2003 年文章《数据库变更的持续集成》 中提出的第五项实践。

Jen 的旅程揭示了什么

数据库变更已成为日常开发的一部分；分支机制显著减少了等待时间、风险与协调成本。Jen 的日常开发循环如今可在数据库层获得快速、隔离的反馈。

在第二部分——Jen 的新操作手册中，我们将解释：是什么能力被提升，以及为何 Jen 整个职业生涯中不得不绕行的“补偿层”可以彻底移除——包括写时复制（copy-on-write）分支机制、支撑该机制的架构设计，以及随之而来的流程优化方法。

在第三部分——Jen 的规模化团队实践中，我们将探讨：当 Jen 是五十名开发者之一，或正在开发白标产品，抑或负责一个包含众多领域的模块化单体应用时，她的故事会如何演变——包括分支创建时的治理机制、DBA 角色的重新定义、“人在回路中”的智能代理机制，以及当 DBA 日程不再沦为工单队列后，平台设计所能释放的新可能性。

对于希望了解本文中 Jen 所用 IDE 工具链的读者，我们还准备了配套内容：配套指南：插件实操演示——即适用于 VS Code / Cursor 的 Lakebase SCM 扩展，提供端到端操作指引。

最后，面向 AI 代理使用的 Lakebase 应用开发工具包（App Dev Kit），以及供人类开发者同步学习的配套电子书，即将发布。