What Neon is, and why I chose it for this blog

I needed a database for the blog you are reading right now, so I spent an evening comparing options. I landed on Neon, and since the reasoning was useful to me, I thought it might be useful to you too.

Neon is serverless Postgres. That is the short version. It is real PostgreSQL, the same database that has been running serious software for decades, but delivered in a way that fits how we actually build today.

Three things make it different from renting an ordinary Postgres server.

It scales to zero. When nobody is visiting my site, the compute shuts off completely and I pay nothing. The next request wakes it in under a second. For a personal site that gets traffic in bursts, that is the difference between a hosting bill and no hosting bill at all.

You can branch the database the way you branch code in git. This is the part I find genuinely clever. Every preview deployment can have its own full copy of production data, instantly, without duplicating storage. If you have ever felt nervous running a migration, most of that nervousness goes away.

It autoscales. Compute grows and shrinks with traffic, so you are not guessing at a server size months before you know what your traffic actually looks like.

None of this is bolted on. Neon separated storage from compute at the architecture level, which is why branching and scaling to zero feel native rather than like features someone added later.

One piece of context worth knowing. Databricks acquired Neon in May 2025 for around a billion dollars. Neon still runs as its own product and the core engine is still open source under Apache 2.0. What I found most interesting was the reason behind the deal. Most of the databases being created on Neon were not being created by people at all. They were being provisioned automatically by AI agents. If you are building anything agentic, that detail tells you something about where this is heading.

Since the acquisition, storage pricing dropped from roughly 1.75 dollars to about 0.35 dollars per gigabyte month, and the free tier doubled its compute allowance.

For my own use, though, the decision came down to something simpler than any of that. I like correctness enforced by the database rather than by code I have to remember to write. Postgres gives me that. A check constraint means a video post cannot be saved without a video id. A unique constraint means two posts can never end up sharing a URL. Neither one depends on me being careful on a tired evening.

If you want to look at it yourself, it is at neon.com.