Most teams I've worked with have a migration sitting in review right now that nobody wants to be the one to merge.
It's usually small. An index, a dropped column, a type change.
The reason it sits there is that staging has a few thousand rows and production has tens of millions, so the only honest thing anyone can say in review is that it looks fine. So it waits for a window, and the windows are Tuesday mornings, and everything else is also waiting for Tuesday morning.
The delay isn't what costs you. What costs you is that people start batching. If a change has to wait for a window anyway, you may as well put three changes in the window, and now the thing you're shipping is bigger and harder to reason about than any of its parts. I've watched a two-line migration become a six-table release for exactly this reason, and everyone involved thought they were being careful.
What branching changes
Lakebase is Postgres, so your application code doesn't change and the things you already know still apply. Storage and compute are separate underneath, and the storage is copy-on-write and versioned, which makes a branch a pointer instead of a copy. You get production data in about a second, it costs almost nothing to hold, and you delete it when you're done.
The comparison people reach for is a snapshot restore, and it's worth being clear about why that's different. A restore on RDS or Cloud SQL provisions an instance and rehydrates storage, which takes minutes to hours and costs a second full copy of your data the whole time it exists. Fine for recovery.
You're never going to run it on every pull request.
Once branching is there, CI can create a branch, run the migration against real volume, time it, run the tests, and throw the branch away. The pull request carries a number. Nine minutes of lock time turns up in review instead of in an incident channel at eleven at night.
Each engineer also gets their own copy, which quietly removes the other thing that slows teams down. Nobody is scheduling around the shared staging database, because there is no shared staging database.
Where it stops helping
Branching won't make a bad migration good. If the schema change loses data, it will lose data on a branch too. You find out on a Tuesday afternoon instead of during a release, which is worth a lot, and it's a different thing from safety.
Knowing a migration takes nine minutes is the start of the work, not the end of it. You still have to decide whether that's a concurrent index build, a batched backfill, or a rethink. Same engineering as before.
And I wouldn't move a system of record onto Lakebase this quarter. We've run it and I like it. It hasn't been generally available long enough for me to tell you what it does at three in the morning in year two, and anyone who says otherwise is guessing.
The effect I didn't expect was the one on appetite. When trying an index strategy costs a second and a deletion, people try four. The migration queue drains because the reason it existed went away, and nobody ever made a decision about it.