Use Neon as your dev environment for AWS RDS: accelerate your workflow while reducing costs
Postgres

Database branching workflows: A guide for developers

Add prod-like data to your preview and local dev workflows

Post image

Modern development demands speed and flexibility, but this is nowhere to be found in database development. Even when using managed databases, database workflows are still slow and prone to errors: setting up new instances takes time, undoing changes is risky, keeping data consistent across environments becomes a pain over time—the list goes on. For many teams, the database is still the place where it’s way too easy to make a fatal mistake and slow everything down.

This is a problem that we’re very familiar with in Neon. In fact, it is one of our main product inspirations. We believe that data and databases should be treated as everything else in our codebase —with the same capacity for safe development and collaboration, iterative improvement, and potential for automation, all without compromising security or jeopardizing engineering time.

Database development done right: ship faster with these database branching guides

To get there, we’re working on a bunch of exciting things in Neon that will be coming soon—but a big leap forward can already be made today. To demonstrate this, we’ve put together a database branching workflows guide in which we walk you through two particular workflows step by step: 

  • Preview environments (one per PR) repo
    • This workflow covers how to automatically create a preview environment for every pull request with its associated database branch. We’ll use Fly.io, Neon, and Drizzle.
    • Once the PR is closed, the preview environment and its associated database branch are automatically deleted. 
  • Local dev environments (one per developer)
    • This workflow covers how to create personalized dev development environments for every engineer in a team using database branching. Each engineer will have instant access to an isolated “copy” of production-like data.  
    • When the work is done, they can sync their dev branch so it reflects the latest state of schema + data in production.

We review the workflows in this video:

Why adopt database branching workflows?   

The two-word summary: you’ll ship faster.

If you want the longer answer, here are some customer favorites:

  • Rapid onboarding.  Every engineer on the team can instantly spin up dev environments with an isolated copy of data plus schema. 
  • Reduced risk. Since branches can be created from past points in time, developers can explore changes with a safety net. Mistakes or unwanted modifications can be easily reverted.
  • Higher quality code. It’s easier to fix bugs when using realistic, production-like data in development environments. 
  • Improved team collaboration. Engineers work in parallel without stepping on each other’s toes. Branches are very affordable, so this isolation costs the team very little.
  • Effortless data consistency. All dev branches can be reset from main in one second, mirroring the same data conditions and schema. 
  • No prod-like data in personal machines.

Get started  

To get started with the workflows, create a Neon project and follow the steps in the guide. If you implement this, we want to hear about it. Find us on Twitter and Discord.