A database per pull request, not a shared staging swamp
Shared staging databases rot. Two people run conflicting migrations, someone leaves test data behind, and within a month nobody trusts what staging actually contains. Branching the database the way you branch the code fixes this at the root: every pull request gets its own database, forked from production's schema in seconds, and thrown away when the branch merges.
Why instant branches change the workflow
A Neon branch is a copy on write fork of the data. It is created almost instantly and costs almost nothing until you write to it, because it shares storage with its parent until it diverges. That means a database branch per pull request is actually practical, not a nice idea you cannot afford.
# create a branch that mirrors production's schema for this PR
neonctl branches create --name pr-482
# get a connection string scoped to that branch
neonctl connection-string pr-482
Wire that connection string into the preview deploy and the reviewer is now clicking through the feature against a real, isolated database. Migrations run against the branch. If they are wrong, you delete the branch and nothing in production ever knew.
Testing migrations safely
The dangerous moment in any release is the schema change. With branching you rehearse it: branch from production, run the migration on the branch, point a copy of the app at it, and watch. A migration that locks a large table or drops a column the app still reads reveals itself on the branch, where the cost is a deleted branch rather than an incident.
Scale to zero is a cost feature
A branch that nobody is querying scales its compute to zero and stops billing for it. So a fleet of pull request databases does not turn into a fleet of idle invoices. They wake on the next query and sleep again when the review is done.
The habit
Treat databases as cheap and disposable, the way you already treat branches. Production stays sacred; everything else is a fork you can create, break, and discard without ceremony. That is what lets a small team move quickly without playing roulette with the one database that matters.