實現演進式資料庫開發：使用Lakebase進行資料庫分支（續）

本文是系列文章的第二部分，探討二十年後演進式資料庫設計方法論的新發展。傳統的資料庫變更面臨共享資源的瓶頸，而Databricks Lakebase的寫時複製分支技術徹底改變了這一局面——建立一個TB級生產資料庫的分支僅需一秒，且初始儲存成本為零。這一突破使得原先僅停留在理想狀態的實踐（如“每個人都擁有自己的資料庫例項”）成為現實。

文章首先回顧了2003年提出的七項原始實踐：DBA與開發者緊密協作、所有資料庫工件與程式碼一同版本控制、所有資料庫變更為遷移、每個人擁有獨立資料庫例項、開發者持續整合資料庫變更、所有變更為資料庫重構、開發者可按需更新資料庫。其中五項實踐因技術限制而未能完全落地：DBA審查為同步瓶頸、獨立例項成本高昂、CI/CD中共享目標資料庫缺乏隔離、重構需要測試環境但缺乏細粒度支援、開發者實驗可能影響他人。

Lakebase的架構將計算與儲存分離，資料持久化在物件儲存（如S3）上，PostgreSQL引擎作為獨立計算層。分支操作僅需建立指向共享儲存的新指標，寫入時只儲存差異頁，因此速度與資料量無關。這一特性消除了實踐4的成本障礙，使每個開發者、每個PR、每個實驗都能擁有獨立資料庫例項。模擬層、記憶體資料庫替代方案（如H2、SQLite）以及本地資料庫容器化均可簡化或移除，DBA的工單佇列也大幅縮短。

基於這些能力，文章提出了2026年的新興實踐：DBA透過PR上的模式差異進行非同步審查（實踐1增強）；所有資料庫工件包括模式差異和遷移測試結果加入版本控制（實踐2增強）；遷移指令碼需冪等性；獨立例項可細粒度到每個PR；持續整合在PR級別自動執行；重構可在不同規模環境預演；按需更新資料庫僅需一秒且不影響他人。此外，破壞性測試成為預設選項（爆炸半徑為零），A/B變體可在並行分支上原型，統一目錄確保了分支的治理一致性，甚至智慧體也能以分支方式進行操作。

CI/CD流程中，GitHub Actions工作流自動建立每個PR的分支，執行遷移並執行測試套件。模式差異以PR評論形式釋出，供DBA和團隊審查。合併後分支自動清理。整個流程無需開發者手動管理資料庫，實現了真正的自動化。

第一部分介紹了開發者Jen一天的場景，本部分則聚焦於她工作的新規則。DBA的角色從門衛轉變為協作夥伴，審查重點從“會不會破壞資料庫”轉向“設計是否最優”。第二部分還詳細闡述了DBA的新責任，包括策略管理和團隊級治理，這些將在第三部分進一步討論。總之，Lakebase的分支技術不僅解除了舊有限制，更催生了全新的開發實踐和團隊協作模式。