I've been using Supabase for two years only until recently when I moved all my new projects to Neon. I figured I'd take the time and note down my thoughts on why this shift happened.
An agents-first company
When testing out Neon, I noticed that a few features were missing, only to find these features were available through the API. Which immediately made me a good impression as nowadays with the amount of intelligence LLMs have, and how good terminal agents are, I strongly rely on personal software - if I need something, I spawn it in a few hours. Which means I need a company that understands this and lets me interact with what I am paying for, from their API.
A quick example I can give, is: [kubeden/neon-budget] - a cli to enforce usage limits that I deployed on my k3s cluster.
Not only do they do this, but their documentation is very obviously made with the thought that "AIs are going to use this" in mind. See their MCP: [neon-mcp-server]
Speed of development
I am a fan of Backend-As-A-Service companies, mostly because of reliability. If I decide to self-manage a storage container, or a database, don't get me wrong - I will succeed. What I am mostly concerned about is my app failing / my cluster over-filling, and me having to deal with backups (which I won't have) and restore. So I am ok paying a small monthly fee to take this trouble away from me.
With Neon, when I started using them, they were still only DB-As-A-Service. I thought, "ehh... it would've been perfect if they had {feature xyz}" - and shortly after, about a month of me thinking this, they release storage, ai gateway, and functions. You can see it in their Discord, they are building at a very high velocity, which is great.
(see the changelog from 4 days ago [neon.com/changelog])
Branching
I think this is obvious.. if you're reading this, you are probably considering using Neon, so you already know about their branching functionality - creation time, separation of environment, etc. etc.
So I won't write much about this. I wrote another big blog post about branching that you can read here: Denislav Gavrilov: Branched Environments
Top comments (1)
The branching section deserves the footnote, because that’s where the convenience quietly turns into a security surface. A branch is a full copy of the data — usually produced from production, so it carries real rows — but it doesn’t carry the app’s auth posture with it. The branch has its own connection string, and whoever holds it has the data: RLS is a property of the role you connect as, and a branch connection is often a role that was never scoped the way production’s is. Two consequences: (1) every branch multiplies credentials — more connection strings across
.envfiles, CI and preview deploys is more places a full-database URL can leak, and a leaked branch string is a full-data leak, not a partial one; (2) a preview branch built from prod inherits prod’s sensitive rows, so it needs the same policy discipline plus a masking/seed step instead of a straight copy. It actually pairs with your API-first instinct — the same script that spawns the branch is the right place to also strip secrets and set the branch role’s grants, so a preview can never be the thing that leaks.