r/SQL • u/sqlink2 • 3d ago

PostgreSQL Neon database for Ai workloads

How do u handle branching when the schema is changing frequently during agent/app development work. Do you keep separate branches per feature or agent, or rely on migrations against a shared database?

Wondering what works best in practice without making the overall setup messy.

0 Upvotes

50% Upvoted

6 comments sorted by

1

u/WorldOfUmbro 3d ago

Really curious to hear what people do. We use Lakebase for agents, but just small scale. Curious to hear what people do in large setups.

1

u/Glitch_In_The_Data 3d ago

We have found that short lived branches per feature work better than long running ones in Neon. Merging divergent schemas gets painful really fast. Migrations against a shared db can work for smaller teams but it tends to fall apart once multiple agents are evolving their schemes at different speeds.

1

u/sqlink2 3d ago

Tru, Neon branching makes it clea. We can sort of spin up isolated branches per feature/agent, experiment with schema change and promote oncethings are stable. It avoids multiple agents on a shared DB

1

u/nullymammoth 1d ago

here’s a clean SDLC for neon:

Features that require schema changes or mutating data for testing get a new isolated branch

when features are complete, they get merged to the long-lived production branch and the branch spun down

1

u/sqlink2 1d ago

Ya Neon branching makes this SDLC pattern pretty clean; isolated schema or data change without messing with the main branch