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