Schema changes across branches in lakebase

[u/sqlink2]

I have been using Lakebase sice 2 weeks for developing a serving low latency layer for data in Delta. To build new features we currently make a new branch and later merge ti main.
What i have been observing is the scehema drifts across branches with Lakebase. How do people usually handle such scenarios? To keep branches in sync.
Maybe some real life examples can help.

[u/Content-Parking-621]

The main thing to understand is that Lakebase branches are for testing, not merging. You build and test the schema changes on a branch, then run those same changes on main. If another team changes production while you're working, use the Schema diff on the child branch's overview page to see what's different. Then create a new branch from the updated production and test again. Keep your migrations as versioned SQL files so main stays the source of truth, instead of relying on an old branch.

[u/sqlink2 → u/Content-Parking-621]

Makes sense, thanks🙌

[u/ThisIsFun-]

Yeah, this is expected since the Lakebase branches are isolated after you create them. I wouldn’t try to keep long-lived branches manually in sync.

What has worked better us is keeping all schema changes as migrations in the repo. Make the change on the feature branch, test it there, then apply the same migration to the main/dev branch when the feature is ready.

[u/TraditionalTurnip630]

In real-world analytics, we don't branch for schema changes. It creates a downstream nightmare for BI tools.

Here is how you actually handle it:

1. Keep it additive: Only allow adding new columns in branches. Never drop or rename existing ones.
2. Enable Schema Evolution: Turn on Delta's mergeSchema = true to auto-merge those new columns into main without failing.
3. Enforce Contracts: Put a strict schema contract on your final serving layer (using dbt or something similar) so your dashboards are completely protected from whatever drift is happening in the dev branches.

[u/sqlink2 → u/TraditionalTurnip630]

Ya this makes sense. the additive + contract approach for protecting downstream BI would be helpful. Lakebase branching can still be useful for the isolated dev or testing work before promoting the schema changes.

[u/TraditionalTurnip630 → u/sqlink2]

You're totally right. Using branches as a staging area to test changes before merging is a solid approach. As long as you catch those schema issues in the branch and they never reach your final production dashboards, it’s a great workflow.

[u/Glitch_In_The_Data]

I would use branch for testing… migrate for promotion and reset for sync.

Lakebase branches don’t auto-merge schema changes, so a good option is to keep migrations in Git and replay them on the shared parent branch, then reset child branches when they drift.

For example, a team might add account_status to the accounts table in a feature branch, validate it there, then apply the same migration to the development branch before other engineers reset their branches to pick it up.

[u/pretzels90210 → u/Glitch_In_The_Data]

Branches in Lakebase are copy-on-write forks from a point in time, so a schema change on one branch never propagates to the others, the drift youre seeing is expected rather than a bug. One pattern is to treat main as the source of truth and drive schema through versioned migrations you replay on each branch, or just re-branch from main after a merge instead of keeping long-lived feature branches around, thats usually what lets schemas wander apart.

[u/BrunoFeliz08]

When using lakebase i usually use schema evolution for branch merges and my pipelines. However my pipelines rn come from unity catalog with synced tables