Netlify
The platform for shipping web apps fast
5.0•49 reviews•2.3K followers
The platform for shipping web apps fast
5.0•49 reviews•2.3K followers
Everything you need to create, preview, and deploy–all in one place. Build with AI or code and go live in minutes.
This is the 17th launch from Netlify. View more
Netlify Database
Launched this week
Netlify Database is a fully managed PostgreSQL database that integrates seamlessly with your Netlify projects. It provides automatic database branching for deploy previews, built-in migration support, and a best-in-class local development experience.
Free Options
Launch Team
Netlify
Hey Product Hunt community! 👋
Today, I'm stoked to share Netlify Database with you, a fully managed Postgres database, built directly into the platform.
Years ago, Deploy Previews made it safe to experiment with code. But the database layer never got that treatment. If you are developer, I'm sure you remember vividly the pain of a shared staging database that is always a little broken. Well, we decided to fix that.
Here is what's special about Netlify Database:
Automatic Branching: Every agent run or Git PR automatically gets its own database branch, seeded from your latest production data.
Zero Production Risk: Schema changes and test records are totally contained. Even our AI agent literally cannot modify production—it only writes migrations for your isolated preview branch. Production stays untouched until you hit publish.
Zero Extra Setup: Whether you are pushing code with Drizzle, or a designer vibe coding/prompting an app into existence, you get the exact same workflow and safety net.
Try it out in 2 minutes ⚡
Head over to Netlify (https://app.netlify.com/start) and try a prompt like:
The agent will spin up the schema, wire up the UI, and give you a working preview running on a real Postgres branch.
Drop your thoughts/questions below, and let us know what you plan to build.
We'd love your feedback! 💬
Unslack
@thisiskp_ "Even our AI agent literally cannot modify production"
Music to the ears of anyone who's had their database emptied by an agent by accident.
2 minutes to try it out? I'll take you up on that offer!
Database branching for deploy previews is one of those features that sounds incremental but completely changes how teams ship. When I was CTO scaling from 15 to 120 engineers, the shared staging database was our single biggest source of deployment friction. Engineers would step on each other's migrations, QA would test against stale data, and nobody trusted the staging environment enough to actually catch bugs before production. We burned weeks every quarter just on database-related deploy issues. The fact that this is built directly into the Netlify workflow means teams get isolated database state per PR without having to duct-tape together Docker containers and seed scripts. That's the kind of infrastructure that lets you move from weekly releases to continuous deployment without the team size to staff a dedicated platform team.
Netlify
@avrisimon thank you so much for the kind words. Great to hear the core problem we’re tackling here resonates with you closely.
This could remove a huge amount of friction for teams working on feature branches . No more worrying about messing up shared data.
Netlify
@gabriel_brooks1 100% - I was doing a lot of testing with Agent runners and knowing every single run across multiple runs had an isolated state to test whatever it needed to inside of was a huge relief!
Adjust Page Brightness - Smart Control
What happens to orphaned branches when a PR is closed or merged?
@kshitij_mishra4
we actually don't automatically delete deploy previews when a PR is closed or merged - this was true before Netlify Database and also true with Netlify Database.
We have an automatic deploy deletion policy base on time. When all deploys referencing a database branch are deleted (automatically or manually), only then the branch is deleted as well - so it doesn't fill up your branch quota (which we've worked to make as high as possible, but it's not infinite). So there are no orphan branches, but also no overly-aggressive and quick deletion of branches that you still may want to keep around for a while, for reference.
We will probably be tweaking the deploy deletion policy soon to have more old deploys auto-deleted, so that more database branches get auto-deleted over time and you won't hit your branch quota and have to start deleting deploys yourself. But in any case it's not going to be stingy or aggressive. You will have ample time to keep older deploys and their branches available for viewing if need be.
branching for deploy previews is one of those features that quietly removes a whole class of staging-data bugs — nice to see it native instead of duct-taped via docker. how does the branch get its data: copy-on-write from main, fresh seed, or empty? and across long-lived preview branches with diverging schemas, does netlify reconcile migration drift on merge or is keeping branches consistent on the dev?
CatDoes
Great launch @thisiskp_ and @Netlify! 🚀
Also curious: what’s the disaster recovery story if something goes wrong in production?
Netlify
@mahdi_nouri hey man! How are you? Thanks for the Q.
Netlify Database's disaster recovery approach is built around reducing blast radius and fast recovery: most changes happen in isolated database branches (deploy previews / agent runs), not directly on production.
Before publishing a production deploy, we take a snapshot of the production database so you have a restore point if something goes wrong (retention varies by plan).
@mahdi_nouri @thisiskp_
There are also classic scheduled backups taken automatically, and whatever the kind of backup - if you restore it - we keep a branch with the pre-restore production branch contents.
That means you can:
Access the contents of that branch to figure out the most-recent data that wasn't in the backup.
If need be, as a final failsafe, our support can revert your restore by reverting to that branch.
There are always a number of ways things can go wrong, especially when merging changes to production having un-intended consequences. We're still working on more tweaks to minimize things going wrong, and providing easier means to recover from sticky situations.
The branched database per PR is the feature staging environments should have had years ago. The amount of "don't touch the staging DB it's broken again" Slack messages this kills is reason enough. Trying the mythical creatures prompt right now.
Netlify
@kunal_s1 that Slack message is universal haha. Thanks for trying this out. Let us know how your builds go!