實現演進式數據庫開發：使用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的分支技術不僅解除了舊有限制，更催生了全新的開發實踐和團隊協作模式。