Enabling Evolutionary Database Development: database branching with Lakebase

Summary

Evolutionary database development treats migrations as first-class CI/CD artifacts, but shared development databases still limit per-developer isolation and fast, realistic feedback. The post follows Jen as she adds location, batch, and serial fields to inventory, coordinating application changes, production-data preservation, schema migration, and tests for storing, reading, and displaying the new values. It contrasts shared databases and simplified local substitutes with Databricks Lakebase copy-on-write branches, created in one second with zero storage at creation, including for a terabyte-scale production database. Jen pairs code and database branches, while CI creates a temporary branch, validates an idempotent and reversible migration, runs application and database tests, and posts a schema diff, enabling combined review and shifting DBA attention toward design and maintainability.

Context

Shared development databases make database changes risky and slow because developers can interfere with one another, must coordinate access, or rely on stale or dialect-mismatched local substitutes. This limits fast, realistic feedback and leaves per-developer production-shaped databases largely aspirational.

Approach / What changed

Use Databricks Lakebase copy-on-write database branches alongside code branches. Developers work against isolated production-shaped databases, while CI creates temporary branches to apply and validate migrations, run application and database tests, and publish schema differences for pull-request review.

Takeaways

• Lakebase branches provide isolated database environments without requiring developers to wait for or coordinate access to a shared development database.
• CI can validate a migration by applying it to a temporary Lakebase branch, checking that it is clean, idempotent, and reversible, and running tests against the migrated schema.
• The workflow lets DBAs review schema design, data integrity, indexing, extensibility, and maintainability instead of serving primarily as a synchronous gate against shared-database breakage.

Related reading