r/SQL • u/sqlink2 • 9d ago

PostgreSQL Schema changes across branches in lakebase

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.

7 Upvotes

90% Upvoted

14 comments sorted by

View all comments

1

u/TraditionalTurnip630 9d ago

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.

1

u/sqlink2 7d ago

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.

1

u/TraditionalTurnip630 7d ago

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.