Published June 1, 2026 · 2 min read
I've been using Neon as my primary PostgreSQL provider for the past year across several projects. It's not just "Postgres in the cloud" the branching model fundamentally changes how you approach database development.
I've been using Neon as my main PostgreSQL provider for the past year, across several projects including this site. At first glance, it looks a lot like other serverless Postgres options. But the way you can branch databases, just like branching code, really makes it stand out. That feature alone has saved me countless headaches.
The ability to instantly branch a database has changed the way I work. Now, every pull request gets its own database branch, copied from production and given a unique connection string. When the pull request closes, that database branch disappears automatically. No more shared staging databases or migration chaos. Because Neon uses copy-on-write, spinning up a new branch takes just seconds instead of the long, painful pg_dump and restore routine I used to deal with.
Another standout feature is scale-to-zero, which often gets overlooked. If you spin up preview branches that only get used for a bit and then sit idle, you don’t pay for compute while they’re inactive just storage. (Pricing - Neon, 2023) For side projects or having a separate database for every pull request, this means you can work without worrying about surprise bills.
If you’re new to Neon, here are a few tips I’ve picked up. First: treat branches like they’re disposable. Don’t build workflows that rely on branches sticking around, unless you’ve set an explicit expiration date. Second: use connection pooling, cold starts after scale-to-zero can mess with unpooled connections, so always use the pooler endpoint if you’re running serverless or edge deployments. Third: Neon’s branching API works beautifully with CI tools like GitHub Actions. I highly recommend creating a branch for each pull request and deleting it when you’re done, instead of having your whole team share a single test database.
Of course, none of this replaces good old-fashioned Postgres best practices. You still need to manage things like indexes, connection limits, and query plans. But with Neon, you can forget a lot of the environment management headaches that used to eat up so much time.
(2023). Neon: Database Branching for Dev/Preview. Neon. https://neon.com/docs/branching
(2023). Pricing - Neon. Neon. https://neon.com/pricing
Chebri, R. (2024). Branch chose Neon for its true Postgres and serverless nature. Neon. https://neon.com/blog/branch-chose-neon-for-its-true-postgres-and-serverless-nature
If this is the kind of problem you are dealing with — type safety, forms, or a codebase that keeps surprising you — a short call is the fastest way to find out whether I can help.