Branching 2.0 became the default last week. Tried it on production. Two things bit me.
ok so branching without git is the default now (since may 4) which means even my no-git lovable side project can have a staging branch from the dashboard. tested it on a real client app this weekend, two surprises i wish someone had warned me about.
setup
small saas, ~120 tables, light traffic. created a branch from the dashboard called add-team-invites. studio opens it in a tab with a little orange badge. ran the migration in there, tested in the studio sql editor, looked good.
clicked "merge to production." this is where i learned things.
surprise 1: seeds don't carry over
i'd inserted some test rows in the branch to verify the migration. branch had ~40 rows of test data in the new team_invites table. when i merged, none of it came along. just the schema. which is correct behavior — you don't want your test data leaking to prod — but the message in the dashboard is just "merged successfully" and nothing tells you "by the way, your data stays on the branch."
if you were treating the branch like a staging environment with realistic seed data, you'll discover prod is empty.
surprise 2: dropping a column with a default sequence cycles
i had a migration that changed team_invites.id from uuid to bigint with a sequence. branch was happy. merge to prod errored out with CycleError: DropSequence ↔ DropTable. apparently pg-delta (the diff engine under the hood) can't always resolve the order when a sequence whose data_type is changing is referenced by a DEFAULT nextval(...) clause.
workaround i landed on: don't change the type of a sequenced column in one migration. drop the default first as its own migration, then change the type, then add a new sequence. three boring steps instead of one clever one.
what's actually good about it
- spinning up a branch costs nothing for short-lived ones. closed mine 90 minutes later, billed for like 2 hours.
- the schema diff view in the dashboard is genuinely useful. you can see exactly what will change before you click merge.
- it works for vibe-coded projects that have no git at all. my non-dev cofounder spun one up on his own.
what i'd do differently next time
- always run the migration on a fresh branch first, even if you only think you're changing one column.
- read the diff carefully. don't just click merge because tests passed.
- migrations that touch sequences or rename anything: split them up.
anyone else hit weirdness on the merge step? curious if the cycle error is just me or a more general pg-delta gotcha.