A contributor for this blog was recently filing a Pull Request to support Postgres. As I didn't want to run that thing locally to test, I needed a cloud service. That is why I tried neon.
Of course I started with Azure, as almost all my stuff is hosted there. For me that was the most logical choice and it did work. So we could finish that blog post, right here, or? Not until I received a message from a developer advocate from neon itself. So here the full disclosure: They wrote me, if I am willing to help them out in some way or another. That could include code snippets, integration code or writing a (sponsored) blog post. Unfortunately, I don't have that much time for another open source project as I am already struggling with all the things I am doing now. Ultimately, I turned down any offer, especially if it involves money. Yes, stupid me does not do sponsored stuff here and does get rich.
But that didn't keep me away from using there stuff anyway and write about it. So before we go into detail, what is neon anyway?
Neon
To put it very simple, they promote it as such:
The database you love, on a serverless platform designed to help you build reliable and scalable applications faster
So basically a fully managed, serverless postgres database with some twists here and there. You can create a free account either via e-mail, google login or GitHub. With a few clicks you have already a free instance running and a dialog tells you how to use it. That was indeed a quite nice experience:
The company behind this product is hosting (presumably some not all) of the code here: https://github.com/neondatabase/neon - also this gives some extra credits from me. I do like that they did this open source. The web ui also has some nice features like a query editor:
Branches
The feature that distinguishes neon from others is called “branches”. It somewhat should work like git branches. The idea is that you can have branches of your database - under the hood this is done via clone of your original database (aka your main branch). That makes it nice to work with your feature branches as well (for example for testing purposes). The whole documentation can be found here: https://neon.tech/docs/introduction/branching
I did not use that feature myself enough, and therefore I am assuming in the next bid, but: Those branches are not as mighty as it sounds. Under the hood there are point-in-time backups (mainly because neon is building on top of AWS or Azure - you can select that) and there is no native way of merging two db "branches" easily. You can reset one branch to another, but I don't see any native way of doing "migrations" but using neon itself without any additional tool. Which is fair to that extent, that you would end up with something like DbUp or EF migrations anyway. For me that was important to state, because git branches are way more mighty.
Pricing
The pricing is pretty transparent. I can not really give you a comparison to Azure or AWS as I am not using any productive Postgres database there and don't feel experienced enough to give an educated opinion. For sure there is a free plan - so you can check that out for sure without binding yourself to anything here.
Shall I use it then?
Well - the free version you can check out for sure. If that is something for you and your team - you have to evaluate to your needs. My first impression was nice. I had a running database in seconds. For your hobby project 19$ might come a bit expensive as there are other, way cheaper, alternatives to that. As I don't want to be affiliated, just use your favourite search engine for this 😉 Also for business - it starts with 700$ to get the 99.95% SLA. I did not find any useful information what SLA they aim at for the lower tiers. I could only find this table which only is valid for the business plan: https://neon.tech/neon-business-sla
The "last modified" date is the 2nd of September 2024 and I wrote this on the 2nd of February 2025
I can not talk much about the consumption for the individual levels as this is highly dependent on your specific workload, but Azure and other vendors do offer similar SLAs for less money's per month. The question is, whether or not the "serverless" nature of the service is enough for you to justify the cost.With this I also mean the "branching" feature which you can easily use for your environments.
My uneducated (and also unsolicited) advice: You pay per use. So if you have a production database that runs anyway most of the time at a predictable rate, you might be better of with the "classical" way. Serverless is maybe useful if this isn't the case and you need to down- and upscale at specific times throughout the day.
As there is a free option, just try it out yourself.
