Article summary
I’ve long been a big fan of review apps, where you open a pull request and get an isolated instance of the application, with your changes, for test and review. But there’s often a catch: the database. That’s where Neon DB comes in.
Review Apps?
What I’ve called review apps are also known as “Preview Apps” or “ephemeral environments.” etc. They’re a feature of managed web hosts like Vercel, Heroku, and Fly. Instead of waiting for your PR to get merged before a non-developer can see your work, you get a temporary deployed app reflecting your current changes (and nobody else’s).
Review apps are particularly effective on a large multidisciplinary team, with multiple features in development concurrently, and multiple roles offering feedback (design review, exploratory testing, etc.).
The Database Problem
Depending on how ambitious you are with your infrastructure (and how capable your component services are), your preview apps likely don’t have independent databases. Instead, for example, they may all share the database of the “dev” instance of the application.
This is a problem when your feature branch makes changes to the database schema. (You clearly don’t want to run work-in-progress feature/foo‘s migrations on the shared dev database.)
On some teams, we’ve just accepted that we can’t use review apps for database-altering branches. Other times, we jumped through hoops to keep database-altering and user-facing changes from sharing a branch, so that the user-facing changes would be previewable.
Or, perhaps you do have isolated databases, but they’re created empty, or filled only with a small, manually-maintained set of test data.
Another option is to populate preview apps from a recent backup of another environment. But, for a large database, that can take a while!
Enter Neon’s Database Branching
Neon DB solves these problems with database branching. When a PR is opened, a fresh database instance is provisioned, based on the latest state of its parent database. It’s copy-on-write, so it’s instantaneous.
Now, your review app’s deployment process can safely apply the branch’s migrations. And now you can test your branch against real data!
Maybe you find a problem with your migration, and want a do-over. You can reset the database back to the state of its parent and go again.
It’s pretty straightforward to configure a CI pipeline to create/teardown the database along with the app. Here’s a GitHub Actions example based on ours.
Benefits
Here are a few more benefits:
- Database branches are fantastic for investigating data-dependent bugs and testing candidate fixes.
- It’s nice to be able to observe realistic database query performance while the feature is still in progress.
- I described how preview app databases are branches of dev, but I didn’t mention that dev can be a branch of prod!
- This post has mostly been about using Neon branches with deployed environments. But you can use them for local development, too! It’s just a couple clicks to create your own fresh branch off of prod to investigate that gnarly bug, or manually test that destructive operation.
- I’m a stickler for maintaining an offline-capable development environment, so I generally have postgres running on my machine. But if you instead want to use Neon for daily development, they have tooling to help with that.
Database branching has been a major boon for my team’s recent data-heavy project, and it’s going to be hard to live without it in the future.