I tried Neon a few months ago when attempting to switch away from a self hosted db. It was a horrible experience, customer support was unhelpful, it was glitchy, slow, and laggy, and even before the price increase their pricing was way too high.
Curious about your self-hosted db - was it also Postgres? How much had you played with pg before you tried Neon? Can you expand what you mean by 'glitchy, slow and laggy'? Slow connection due to cold starts? Scale-up? General inconsistency in performance? What kind of data volumes were you working with?
I ask because my experience with Neon has been completely different to what you just described. Ever since their 'closed beta' days, it has always 'just worked'. Their CLI has been great, none of my automation has ever bombed out without good reason, and I've never seen it cost me more than I expected. Notably, I was also able to self-host it with relative ease, and found that they actually encouraged people to do so. (In contrast, there are a number of similar 'open source' offerings such as Supabase that I've tried self-hosting, and found that while their core codebase is on GH, it is extremely difficult to deploy outside of their own environment. Not intended as a dig at Supabase, they do some really great work and contribute a ton back to the Postgres community - I'm just using them as a relevant example).
As an aside, I've also met people from Neon at various conferences, including co-founder Heikki. They all struck me as genuine Postgres enthusiasts & great fun to geek out with. Neon (like Supabase) have been _really_ pushing the envelope on Postgres for the last couple of years, and have sponsored some significant developments & proposals. In my view they're a 'real OSS company'. While that probably does rose-tint my view of them a little, that's important to me & makes me happier to give them my money. They've certainly done more for Postgres than AWS ever has.
Thank you for the confidence and praise! I do believe we, Neon, try to be as open as possible while also trying to build a business around this open source product.
I'm a proud PostgreSQL contributor myself and value the work of my collegues highly. However, it should be said that AWS' RDS PostgreSQL offering in late '13 significantly helped increase PostgreSQL adoption, and the recent contributions by AWS' own PostgreSQL Contributors Team should not be discounted. IIUC, their Aurora PostgreSQL offering also was the inspiration for Neon as a product, so I don't think that your last jab to AWS was justified like that.
I met with Heikki in Estonia for local Postgres user group meetup. That was when I first time heard about Neon. He is a true Postgres hacker and very cool guy to talk to
Hey, we do want to add numbers back to that page. The issue was that the original numbers were inaccurate.
"The goal of this metric is to represent the health of a system. However, we found this binary “is there an incident or not” approach wasn’t accurate for describing our service. For example, in the past 30 days, 99.9% of projects hosted on Neon had an uptime better than 99.95%; however, the status page displayed 99.89% uptime."
When Neon goes down twitter lights up, we haven't had it for a long time now.
Internally we are measuring the number of projects under 5 min in the last 30 days and it's been lower double digits over 700K+ total databases under management.
A TON of effort is going there, twice a week standups, tightening our processes and quality across the board, a standing item in our monthly board meetings. While stability is black and white, what goes into delivering it is a long tail of small and large improvement and a major team effort.
woof, that does not sound good. Can you say more about how you were connecting? What was slow / gitchy and laggy? Feel free to reach to over DM to me with your project details.
> Feel free to reach to over DM to me with your project details.
I’m not the parent commenter but just giving you a heads up that your HN profile doesn’t list any socials so I don’t know if people will find how to DM you. Unless you guys have a public Discord or something and it’s implied that that is how people would be able to DM you.
We were connecting over `pg` (NodeJS). The web dashboard was constantly logging me out and was overall a mess (although I'd imagine it might be a bit better now, given GA?). There's no DMs on HackerNews btw
We did not hide it because it was going down. We hid it because it was an incorrect calculation. We are currently re-doing the our status page to look more like Snowflake's.
I don't have any proof, but you'll just have to trust me, which could be a tough ask. Neon really tries to be transparent in internal and external communication.
We're self-hosting Neon with an internal Kubernetes operator (keep your eyes out for more info) and we're incredibly happy with Neon's technical solutions. I'm not sure we'd be able to build our company without it :o
The by far biggest is being able to scale it on top of Ceph, while getting performance from NVMe disks on Pageservers. This enables us to increase efficiency (aka cut costs) by 90%+ in a multi-tenant environment.
Of course we don't get the same out of the box experience as CNPG, but considering we have the engineering capacity to build those parts ourselves, it was a no-brainer!
i'd love to learn more about what you're doing! if you haven't already, please send a message. definitely want to hear lessons learned with your k8s operator.
Branching the whole database (data included) seems really great. Congrats!
It does seem a bit pricey though. For $69/month (Scale), I could rent a dedicated server with 8 dedicated CPUs, twice the RAM and 20x the storage (and that's physically attached NVMe in raid 1), and have money to spare:
https://www.hetzner.com/dedicated-rootserver/matrix-ax/
$69/month is peanuts for anyone running something that hopes to make any amount of money. Developer and operational experience, uptime, etc. seem way more important. Just getting to skip dealing with all that nonsense and focus on whether your idea / startup has any value whatsoever seems far more important.
(Obviously if it's just like a hobby deal then run it on a cheap VPS).
Unless it's enough money to spare to pay someone to manage Postgres on the server and scale it up and down as needed, this isn't that useful a comparison.
As an avid self-hoster, by all means, self host Postgres! But self hosted Postgres is not the same product as managed Postgres.
Cheeky jokes aside, you can definitely go down the hetzner/VPS route. Not everyone has the expertise or desire to spend time doing so, but if you do, then go for it I say. We have some nifty features that are non-trivial to recreate, but again, it depends on your needs.
I switched my company over to Neon from PlanetScale. In part for the ability to scale up/down easily and also so I could run multiple databases on the same cluster.
I also looked at (and spun up) RDS but Neon was way easier to work with and scales to 0 (Aurora Serverless is trash IMHO). Neon starts very quickly as well (hundreds of milliseconds in my testing) which is pretty awesome.
I have nightly backups dumped to Cloudflare R2 from a GitHub action.
If Neon announces they're shutting down, migrating the database to another provider is a bash 1 liner and an hour of downtime.
If Neon just "goes dark" I can recover from the nightly backup and lose at most 24 hours of data - data that is denormalized into other systems and can be manually recovered if absolutely necessary (but probably not).
Not every company is the same, but for many use cases the database layer is an inconsequential decision as long as the API is fungible for your use case.
Not every decision is a 1-way door.
The most important way you can spend your time when making a 1-way door decision for a company isn't picking the right door. It's turning the decision into a 2-way door.
That's fair. It was something I was worried about but I knew the worst-case was I could spin up RDS and move over to that. This is for my personal company and the load on the software is very spiky with long periods of near-zero activity (we did the switch over in one of those zero-activity periods). That gave us an easy on-ramp to testing this DB as a replacement.
I have 1 database per client and their needs almost never overlap so I wanted to share the underlying server/cluster between them. You can't do that on PlanetScale. Aside from that I liked working them.
I’m not extremely well versed in the topic so forgive the ignorance: how does this differ from AWS Aurora’s offering? is pricing or scaling different. It’s not immediately obvious why you would want to use this instead.
(Neon ceo)
1. You should try and see the experience
2. It scales to 0. If you have lots of projects aurora costs really add up
3. It supports branches and integrates with vercel. You can have environment for every dev and every pr.
4. We will be on multiple clouds soon
5. We are just getting started
I wish you the best of luck, but please know that for a lot of us time is money and also literally our most invaluable / irreplaceable asset, and also tech startups who want us to make a bet on them need to have some sort of value proposition given the risk of "you might die or disapear or be aqui-hired in three months after we moved" so I would encourage to not answering this as your 1).
To me the instinctive reaction is "it's for when you will have time to fool around and figure it out by yourself". It is my opinion only, it's worth nothing more than that, and I realize you didn't ask for it, but I just wanted to let you know.
(From molnett.com) For us that self-host, the architecture of building cold storage on top of Object Storage and warm storage on top of NVMEs is unbeatable. It enables us to build a much more cost-effecting offering while keeping Postgres as our database.
Is 5 a reference to how you naked the prices so Neon doesn’t work for light-workload, moderate storage databases anymore? $69+ a month for a Segment data warehouse holding 10gb is obnoxious. It was under $10 before the switch. What’s next? $690/mo?
Why is storage priced so high? Depending on the plan it looks like it can cost anywhere from $1.50 to $1.75 per GB. That feels pretty excessive; maybe I’m missing something that causes it to be so pricy? It actively discourages me from wanting to use it for a hobby project, because the storage costs would send my bill to over $100/month before I even use any compute.
Storage costs are something we are going to be looking at soon. If we can reduce our cost of goods sold, it is possible to pass on savings to consumers.
The feature they call "branches" is more accurately to call "snapshots" or "checkpoints". Creating CoW writable versions and rolling back to past versions - that's snapshots. Branches imply merging, which is a huuuge can of worms, even if we apply last-write-wins, cause referential integrity and things, can't just merge postgreses.
Readit News
I've migrated my customer's workloads over to neon's managed postrgres and it's been consistent and reliable for the use case.
I have nightly backups pushed to Cloudflare R2 triggered by a GitHub action for disaster recovery but, to date, I haven't had to touch those.
I ask because my experience with Neon has been completely different to what you just described. Ever since their 'closed beta' days, it has always 'just worked'. Their CLI has been great, none of my automation has ever bombed out without good reason, and I've never seen it cost me more than I expected. Notably, I was also able to self-host it with relative ease, and found that they actually encouraged people to do so. (In contrast, there are a number of similar 'open source' offerings such as Supabase that I've tried self-hosting, and found that while their core codebase is on GH, it is extremely difficult to deploy outside of their own environment. Not intended as a dig at Supabase, they do some really great work and contribute a ton back to the Postgres community - I'm just using them as a relevant example).
As an aside, I've also met people from Neon at various conferences, including co-founder Heikki. They all struck me as genuine Postgres enthusiasts & great fun to geek out with. Neon (like Supabase) have been _really_ pushing the envelope on Postgres for the last couple of years, and have sponsored some significant developments & proposals. In my view they're a 'real OSS company'. While that probably does rose-tint my view of them a little, that's important to me & makes me happier to give them my money. They've certainly done more for Postgres than AWS ever has.
I'm a proud PostgreSQL contributor myself and value the work of my collegues highly. However, it should be said that AWS' RDS PostgreSQL offering in late '13 significantly helped increase PostgreSQL adoption, and the recent contributions by AWS' own PostgreSQL Contributors Team should not be discounted. IIUC, their Aurora PostgreSQL offering also was the inspiration for Neon as a product, so I don't think that your last jab to AWS was justified like that.
https://pgug.ee/meetings/06/
(Neon Postgres engineer)
Hey, we do want to add numbers back to that page. The issue was that the original numbers were inaccurate.
"The goal of this metric is to represent the health of a system. However, we found this binary “is there an incident or not” approach wasn’t accurate for describing our service. For example, in the past 30 days, 99.9% of projects hosted on Neon had an uptime better than 99.95%; however, the status page displayed 99.89% uptime."
(source: https://neon.tech/blog/multi-tenant-uptime)
(Neon engineer)
Edit: to be more specific, we will have a new calculations similar to how Snowflake does theirs.
Internally we are measuring the number of projects under 5 min in the last 30 days and it's been lower double digits over 700K+ total databases under management.
A TON of effort is going there, twice a week standups, tightening our processes and quality across the board, a standing item in our monthly board meetings. While stability is black and white, what goes into delivering it is a long tail of small and large improvement and a major team effort.
We will also update the status page soon.
(neon empl)
I’m not the parent commenter but just giving you a heads up that your HN profile doesn’t list any socials so I don’t know if people will find how to DM you. Unless you guys have a public Discord or something and it’s implied that that is how people would be able to DM you.
I don't have any proof, but you'll just have to trust me, which could be a tough ask. Neon really tries to be transparent in internal and external communication.
(Neon engineer)
Deleted Comment
Are you able to handle branching as well?
It does seem a bit pricey though. For $69/month (Scale), I could rent a dedicated server with 8 dedicated CPUs, twice the RAM and 20x the storage (and that's physically attached NVMe in raid 1), and have money to spare: https://www.hetzner.com/dedicated-rootserver/matrix-ax/
(Obviously if it's just like a hobby deal then run it on a cheap VPS).
As an avid self-hoster, by all means, self host Postgres! But self hosted Postgres is not the same product as managed Postgres.
By all means, self-host Neon and come talk about it in our Discord (https://neon.tech/discord)!
Cheeky jokes aside, you can definitely go down the hetzner/VPS route. Not everyone has the expertise or desire to spend time doing so, but if you do, then go for it I say. We have some nifty features that are non-trivial to recreate, but again, it depends on your needs.
this also doesn't cover 100% uptime, but only 300h, and you will pay extra for each extra hour.
I also looked at (and spun up) RDS but Neon was way easier to work with and scales to 0 (Aurora Serverless is trash IMHO). Neon starts very quickly as well (hundreds of milliseconds in my testing) which is pretty awesome.
I have nightly backups dumped to Cloudflare R2 from a GitHub action.
If Neon announces they're shutting down, migrating the database to another provider is a bash 1 liner and an hour of downtime.
If Neon just "goes dark" I can recover from the nightly backup and lose at most 24 hours of data - data that is denormalized into other systems and can be manually recovered if absolutely necessary (but probably not).
Not every company is the same, but for many use cases the database layer is an inconsequential decision as long as the API is fungible for your use case.
Not every decision is a 1-way door.
The most important way you can spend your time when making a 1-way door decision for a company isn't picking the right door. It's turning the decision into a 2-way door.
I have 1 database per client and their needs almost never overlap so I wanted to share the underlying server/cluster between them. You can't do that on PlanetScale. Aside from that I liked working them.
I wish you the best of luck, but please know that for a lot of us time is money and also literally our most invaluable / irreplaceable asset, and also tech startups who want us to make a bet on them need to have some sort of value proposition given the risk of "you might die or disapear or be aqui-hired in three months after we moved" so I would encourage to not answering this as your 1).
To me the instinctive reaction is "it's for when you will have time to fool around and figure it out by yourself". It is my opinion only, it's worth nothing more than that, and I realize you didn't ask for it, but I just wanted to let you know.
> (Neon DevRel here) [...] However, many production databases won't scale to zero often.
I think a planned consistent message might be best
Dead Comment