Over the last decade, nearly every part of the software development stack has evolved to support faster iteration, better automation, and less oversight. But one layer has stubbornly resisted this evolution – the relational database.

The stack evolved, the database stayed behind 

In many ways, this makes sense. Databases are supposed to be robust, reliable, boring – they hold your source of truth, you don’t want them to be too exciting. But that mindset came at a cost. Databases became the scary piece of the stack – slow to provision, hard to reset, risky to touch – and working with them started to, in many ways, suck.

The managed databases most teams interact with run pretty much like they did a decade ago – they’re built on serverful architectures, running on VMs. Some vendors have added a few nice experience touches, and the surface may feel modern – but there’s not much innovation under the hood. This legacy shows up in workflows that haven’t changed in years:

• Shared staging databases that get manually wiped and re-seeded
• Long-lived environments prone to drift
• Fragile seed files and teardown scripts
• Tests running against data that looks nothing like production…

The agent era exposes the cracks

Developers have been putting up with this for years, but what finally broke the pattern wasn’t the developer pain – it was agents.

With the initial launch of Replit Agent, the AI era for infrastructure began. Today’s agents can go from prompt to deployed app in seconds – they write code, run migrations, provision databases, and deploy autonomously. This simply doesn’t work with the old, slow, heavy infra model for databases. Agents are pickier than human engineers, who learned to work around the pain—agents won’t. They can’t wait 10 minutes for a database to spin up or resize, they can’t run pg_dump/restore workflows while a user waits to run a test, and the company behind them can’t afford to pay $25 per instance to AWS when it might be thrown away five minutes later.

It’s time to set a new standard for how databases fit into development workflows. The work those database startups like Neon began years ago (reimagining databases for developers) was made urgent by the needs of agents, which in many ways are fundamentally the same as the needs of developers. 

Which brings us to branching.

Database branching: the missing primitive 

Ask developers what they want from a database environment. The wishlist is clear – they want something that’s easy to spin up, automatically scalable, integrated with the rest of the stack, cost-efficient, and pretty much invisible most of the time; they also want something that’s robust and safe to experiment with, something that doesn’t break everything when they test a migration or debug a failing query – a database that’s somehow forgiving.

This isn’t that different from how developers felt about touching codebases not that long ago. Version control and branching transformed how we work with code, giving engineers the ability to experiment safely, isolate changes, review work in progress, and collaborate without risking the main codebase. Now imagine applying that same model to your database – why not introduce branching to Postgres (the de-facto standard for relational databases used by millions of teams today) and unlock a similar level of agility?

This is what we’ve been working on at Neon. From the very beginning, we had the concept of a database branch in mind – not as a feature but as a primitive. Something foundational to give developers the ability to create safe environments instantly, to experiment and roll back without consequence and to move fast. 

But the biggest (and most underrated) power of branching databases is confidence. Branching breaks down the fear that’s built up around relational databases and makes them feel safe to work with again. It gives developers a way to try things without hesitation. If something breaks, you reset. If you want to compare two versions side by side, you branch and test. If an agent or a teammate messes something up, you go back in time. You’re much more free to build.

Branching Postgres requires a new architecture

But here’s the catch – you can’t fake this. Branching and legacy database infrastructure don’t mix – you can’t just clone an instance, give it a new name, and call it a “branch.” Building a real branching primitive for Postgres requires heavy architectural work that most database platforms simply haven’t done. Others claim to offer branching but do it by duplicating entire instances or snapshots behind the scenes, but that’s still too slow and heavy. These approaches to “branching”, 

• Require full storage duplication, even if nothing has changed
• Take a long time to provision, especially for large datasets
• Accumulate costs linearly with every copy
• Offer no native reset, no built-in time travel, no real ephemerality

To make branching real, you need to start with a different foundation. That’s what we did at Neon, where we rearchitected Postgres from the storage layer up to support instant, copy-on-write branching as a first-class primitive. Branching on Neon is dependent on multiple architectural elements that took us years to build (and that we’re still working on) 

• Decoupled storage and compute with copy-on-write: Each branch must have its own compute endpoint, while sharing the same underlying storage unless it diverges. When a branch is created, it should reference the exact same data pages as its parent – new data is only written on change. This is what makes branch creation instant and storage-efficient, without forcing the user to duplicate data.
• Parent/child branch relationship: The engine must track changes per branch and maintain visibility across versions. This allows you to query or restore the state of any branch at any point in time.
• Time travel: Developers should be able to create a new branch from any past moment instantly, regardless of the size of the database. This must feel lightweight and immediate – not like traditional snapshot or restore systems.
• API lifecycle management: Branches should be created, reset, promoted, or deleted programmatically. They must scale to zero when idle, resume quickly, and fit naturally into automated workflows.

The combination of all these innovations is what makes branching viable not just as a UX improvement but as a core building block for modern workflows. Once you have it, entirely new patterns emerge.

A glimpse into the future 

The future of software won’t be built by humans alone. It’ll be built by agents – and branching is what will power this new development experience where every version is saved, every failure is reversible and iteration is fast and fearless.We’re already seeing this in production.

Replit already lets users preview and roll back to any version of their app – code and database included. Behind the scenes, it’s Neon branching doing the work, quietly making the whole thing feel effortless. This kind of experience simply wouldn’t be possible on legacy infrastructure.

We’re convinced branching will become the default way of interacting with databases – not just because it’s faster or cheaper but because it fundamentally reshapes the relationship between developers, agents, and the database. It creates a new mindset – one where iteration is constant, rollback is instant, and the boundary between code and data begins to disappear.