Forkable infrastructure is emerging as the next primitive for data infrastructure.
We’re seeing more customers ask for not just snapshots or backups, but true branches of their database: forks you can spin up instantly, test against safely, and (sometimes) merge back.
@supabase and
@neondatabase are both pushing in this direction, but with different philosophies:
▪️Supabase Native Migrations → tightly integrated with GitHub and CLIs. A PR spins up a branch, runs SQL migrations, and on merge those migrations are applied to production.
▪️Neon ORM-Powered Migrations → instant copy-on-write forks, but migrations are left entirely to your ORM or toolchain (Prisma, Drizzle, Flyway, etc.).
The nuance: not all schema changes are the same:
— Adding tables or columns touches application code: natural for an ORM to own.
— Adding an index or constraint rarely requires code changes: you want to test these directly in the DB, often for performance reasons, before committing.
AI coding agents may push this divide further. If your program already uses an ORM, an agent will almost certainly stay within that framework: models migrations together. That works for schema tied to code. But it doesn’t address database-only optimizations, the kind of changes developers want to experiment with directly inside a fork.
Forkable infra sits right at this intersection: a tool for both human creativity and agent-driven automation.
I’ve been thinking a lot about developer workflows for data infrastructure. Should forkable infra be opinionated about migrations, or should it stay raw and flexible, letting humans and agents layer their own workflows on top? Or perhaps somehow both?
Curious to hear your thoughts. What do you think?
#ForkableInfra #Postgres #DatabaseBranching #DevEx #AIagents