Post

Meet the new Netlify Database. Fully managed Postgres, built into the platform. Every agent run automatically gets its own database branch. Here's why that matters. 🧵 www.netlify.com/blog/netlify...

3 reposts23 likes

What strikes me about the database branching concept is how it handles the isolation problem. It sounds useful for testing, but I am curious how it manages data when you need to actually compare behavior across different agent runs.

Years ago, Deploy Previews changed how we ship code. Safe to break things, easy to roll back, every branch isolated. The database layer never got that treatment. One environment, shared, always a little broken. That's what we fixed.

When you start an agent run, Netlify provisions a Postgres branch based on the latest production data. Schema changes, test records, half-baked experiments, all contained. Production stays untouched until you choose to publish.

The agent literally cannot modify production. Not a permission flag, not a toggle. It just cannot reach it. It writes SQL migration files as it works. Those run against your branch during preview builds. Production is only modified when you go live.

How a schema change flows end to end: 1. Agent writes code and a migration file 2. Preview build runs the migration on your branch 3. You test. Break things. Add junk data 4. Publish when ready 5. Netlify applies the right migrations to production No 2am rollbacks.