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.
"Unlike AWS Aurora we decided to open source all the changes in Postgres and also send them upstream as well as fully open source our cloud native storage."
You can find replies from folks in this thread as well discussing self hosted deployments and you can find an entire discord channel dedicated to that topic here: https://discord.gg/92vNTzKDGp
I'm not associated with Neon and I've never used it before and I certainly don't disagree with your sentiment, but it seems like Neon has gone above and beyond in making sure that workloads could continue to run in the event the company fails and broadly assuaging those concerns.
The full control plane is not open source, so if you use tenants or many of the not-in-postgres features you will need to implement the control plane. It's not too much work to do so - there's already a few open source projects starting to do so - but just be aware of that.
We have a toy control plane implementation in the neon repo aliased to `cargo neon`, but also available as `neon_local`. I'm honestly not sure if open-sourcing the production control plane is in our future.
I could've sworn I closed my Reddit account. I thought neon was meant to be a bit like Git with data, with branches etc, as well as autoscaling and nice stuff like that.
Neon won't pull the rug from under an active production database by scaling to 0 when there are still active queries, instead it'll scale databases to 0 only after a longer period of inactivity. So production databases are less likely to scale to 0 because they generally are active most of the time, yet Neon does scale to 0 when it's possible and allowed.
(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?
I don't get how this achieves point in time recovery? I assume I'm misunderstanding some fundamental part here.
If the branches are achieved using a COW file system, how does this part from the blog post work?
> Suppose a developer fat fingers a table or a database out of existence? No problem, move the branch to the second before that event happened.
How can I go back in time arbitrarily here? I would have assumed that you can only go to existing snapshots if the underlying method is a COW file system.
PostgreSQL writes changes to disk using WAL for consistency. Every WAL record is a set of changes to the PostgreSQL data directory (data files, metadata, ...) that need to be persisted together.
Neon indexes this WAL, and restores pages to the right version by replaying all WAL from the previous page snapshot up to the right version, allowing full point-in-time for all persistent tables in the database.
Calling it "branches" does seem misleading. For instance, would this also work across major PG versions? afaict, it is just not possible to merge two differently versioned postgres-es
Branching in Neon should be interpreted more like the branches seen in graph theory's trees rather than the featureset exposed by git: the whole history of a Neon project is a unidirected graph with a single path between any two points in the history.
> For instance, would this also work across major PG versions
As for multiple major versions: We currently can handle multiple major versions in different tenants on the same pageserver/safekeeper servers, just not for the user's PostgreSQL instance. Major version upgrades (by way of pg_upgrade) are something we're working on, but that's still quite far down the road.
> afaict, it is just not possible to merge two differently versioned postgres-es
Correct, and AFAIK we don't actually advertise anything related to merging histories. If we do, please do tell where, so we can correct that.
This is achieved through our Pageserver. The pageserver ingests streams of WAL, and so contains both snapshots and deltas. This lets us efficiently seek to any LSN by replaying page deltas on top of the nearest snapshot (we call it the GetPage@LSN API).
Sure! Each instance of Postgres runs inside a qemu VM, inside a kubernetes pod. The VM provides isolation, autoscaling, metrics, and (eventually) live migrations. These VMs share AWS Metal nodes.
Nice work Neon! I’ve used it a number of times and am impressed at how quickly databases become available. Leaps and bounds faster than RDS. it’s amazing when you need something now.
as a "mere user" of the JS or API endpoints, should I think one is better than the other? To me it doesn't really matter if it's Supabase/Neon, Turso, or D1 powering it as long as... it works
I'd probably care because of the ecosystem. There's a bunch of developer tooling and mature ORMs around postgres. Granted, those same libraries/frameworks probably work with sqlite too.
I guess it's just trust. I trust postgres more than I trust sqlite for building big apps.
One last point: I'd look at feature set of both offerings. I suspect the features of the postgres offering to be more conducive to scale.
With Turso you get an sqlite database behind a SDK or an (HTTP REST) API endpoint.
With Neon you get a postgresql database over a postgres wire format connection.
So if you have an already existing app speaking postgres to a database somewhere, Neon is a drop-in-replacement, while Turso would require adapting to their custom API.
If you are creating a new service, you might need/want to take advantage of e.g postgres extensions [0] for storing geographical data or pg_vector for similarity searches etc. Or you simply need more stringent serialisability promises than what libsql / turso can provide.
But if you just writing something new from scratch and have "simple" demands, I think something like Turso looks cool (and cheap!).
The founder of Turso explained how they can have such a generous free tier in a tweet:
> Lots of people have been reaching out to me asking if they should expect our free tier to be around, given recent news.
> Yes, you can expect our free tier to be around.
> The main reason we built a service on SQLite is that we knew we could build the most efficient thing in the market with that. I usually keep these number semi private, but last month Turso had over 20,000 databases under management - in all plans - and our Cloud bill was less then 3.5K USD.
> I sympathize with Planetscale, in the sense that running a company is hard and you sometimes have to make hard choices. But look beyond words, into cost structures and incentives:
> Of course our service is expensive to operate, like any service, but most of it is staffing. We'll never find ourselves in a situation where killing our free tier will make any dent in the profitability of the company.
Appreciate yall being active in here but this doesn't really answer the question. Neon looks really interesting to us, we're currently paying Heroku for a standard-5 postgres plan at $1400/month. But that's mostly for the 1 TB of storage, I have no idea how much "compute" we currently use.
(Neon PM) Do you have have an idea of the RAM or compute your application needs Many applications can run 24/7 with 1 GiB RAM on the Launch plan at $19/month.
Our Sales team would be happy to talk through pricing with you. Do you have any suggestions on where we could clearer to people like yourself who are in the same position?
Storage costs can be calculated as something along the lines of:
size of current database * retention period (configurable) + compute hours
There are some limits. Architecture wise storage indefinitely and compute up to the largest bare metal node on Amazon plus as many read replicas as you want.
(Neon PM) This is true and very often production applications need access to their database 24/7, so they benefit from the serverless nature of autoscaling.
This is valid. However, many production databases won't scale to zero often. The serverless proposition is still valuable if you factor in the development, test, and staging environments scaling to zero plus our autoscaling that doesn't require downtime or dropped connections.
For guaranteed message delivery, you're probably best of using a messaging system designed with that in mind instead of listen/notify.
I find it really sad how many communities these days use Discord rather than a searchable forum. There's no specific Q&A format to hone in on specific solutions.
To provide more context, our original plan was to launch the GA on March 22nd. However, we decided to move the date to April 15th because a few projects required additional time to complete. Last week we saw Supabase announcement but we didn't know what is that about and decided to not to move our date again.
Storage is the most surprisingly expensive part now. $1.50/GB is kind of a tough pill to swallow. We've been exploring the idea of shifting from Aurora to Neon. With the recent pricing changes, our bill has exploded even with almost zero usage of compute time.
Even if backups/history were taking up zero space, $1.50/GB seems really high for raw storage. The rest of the pricing seems reasonable to me. We're only around 100GB right now, but can see that ballooning up in the future and raising some concerns.
By the way, I do want to say that branching is a game changer. The recent usability improvements like graphs/metrics and being able to reset a branch to the state of another one without affecting the endpoint is so nice. We previously had a messy script that took care of creating a new branch, moving endpoints, renaming, deleting, etc.
More fine-grained permissions for users on projects would be my number one ask at this point, but overall, I really appreciate the improvements the Neon team has made in recent months.
Neon keeps an NVME cache in the Pageservers, and it also keeps copies of the data in S3, one for the main storage, and one for the backup case. The data also gets stored on special replicated storage (Safekeepers). So it might be in 6 different places at the same time (3 safekeepers, 1 pageserver, 2 S3 buckets), details depending on the data's lifecycle through the system.
This architecture delivers really good safety: Once your transaction commits, the data is already replicated across different AZs, and this is done without there being an S3 request each time. It also means that Neon can deliver features like branching.
> So it might be in 6 different places at the same time (3 safekeepers, 1 pageserver, 2 S3 buckets), details depending on the data's lifecycle through the system.
Permissions improvements have been duly noted by others, so expect that work to begin sometime in the near future.
Reducing our COGS is very important, and also something that we will be working on. I would definitely reach out to our sales team for a more custom quote.
Yeah, I am not sure what "scales to zero" really means. The storage costs + pre-paid compute could essentially buy you an AWS instance. Sure you do get things configured from the get-go but if you can get your way through Terraform that can work too.
Either way, if you get big enough (will use more storage + compute), it makes sense to move. I'd be against such platforms as they make changes to Postgres that might make you depend on them.
One case where scale to zero can help is if your main branch scales to zero, that means more compute hours for your non-main branches.
FWIW, Neon is really "just" Postgres. I can't think of anything Neon specific that would lock you in, other than that we don't support certain kinds of extensions yet. But if you were going to use those extensions, then you probably wouldn't have picked Neon in the first place. I also wouldn't consider that a lock-in. Do you have any examples that you might be aware of in Neon? Postgres compatibility is something that we take very seriously.
This almost feels like how cloud providers charge excessive fees for excess bandwidth. Storage is cheap, even with replication, especially at Neon scale.
I've been using Neon's serverless Postgres for the last 6 months and I'm extremely impressed! As a developer, it has been a game-changer in terms of productivity and letting me focus on building features rather than managing database infrastructure.
Congrats to the amazing Neon team on launching serverless Postgres to the world!
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.
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
node-postgres (pg, probably more specifically pg-pool) doesn't do too well with serverless, not handling TCP connections killed while in the pool (or something): https://github.com/brianc/node-postgres/issues/2112 (open since 2020)
A nice marketing opportunity for Neon/Supabase to get a fix officially released.
If you're interested, our team also takes negative feedback to create points of emphasis on where we can improve. But I understand that takes time out of your day.
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."
How many times do you expect to slice it? "For 99% of days this year, 99% of our customers have experienced 99% reliability for 99% of their users, we're 99% sure"? (That's just the long way of saying 95%)
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.
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
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.
good point - yeah D1 i think is sqlite based. for my toy projects that hasnt mattered so far but for more complex projects i see how this is a big difference, thanks for pointing out!
It looks like the compute for the free tier is free (for your main branch) + 20h for branches, but the lowest paid tier is 300h for all branches. Can anyone using this speak to that? I've seen this trend where free tier has better features than the lowest paid tier.
Edit: Love to see several Neon folks in this thread from various parts of the company. It's always good to get insight from engineering, devrel, product, and CEO.
(Neon PM) If your project uses less than 500 MiB storage, our Free plan might be the best plan for you. If your project needs more storage, branches or larger compute then a paid plan might be a better fit: with Launch you can run your project 24/7 at $19/month.
The Launch plan includes 300 compute hours. All your computes draw from this, regardless of whether or not it's a primary branch.
For a simple comparison, let's assume you only use 0.25 vCPU computes and your primary compute runs 24/7 (~750 hours per month) to keep the comparison easy:
1. On the Free plan, you can have the primary running 24/7 plus an additional 20 hours for other branches.
2. On the Launch plan, you can have the primary running 24/7 plus an additional 450 hours for other branches. And of course the 10 GiB storage + other paid features.
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.
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 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‘d argue that the most important way to spend the time is on building something customers want and not micro-optimize with shiny database vendor of the week. Get a boring managed Postgres and it‘ll scale for a very very long time, it‘s well understood and if you hit the limit, that‘s a good problem to have and there‘s many solutions for that when the time comes.
My customer profile at the time was mom-and-pop small businesses. Bespoke application development that automated back office work delivered on ~6week timeline.
The size of their tech department was 0.
The goal with the architecture I delivered was to delegate as much as possible below a vendor boundary.
My solution was:
Cloudflare workers for compute.
R2 for storage.
Neon for database. HTML/JS/CSS for the frontend.
Neon wasn’t a micro-optimization. It was the only vendor in town that would own that much of the DB layer’s responsibility (D2 wasn’t prod ready yet).
12months in and so far so good. I’ve had to “come back in” for a total of 30minutes of maintenance when mobile Chrome broke uploading a photo via camera.
Wouldn‘t you want the most boring solution that‘s unlikely to change in the next 5 years for this use case? (AWS etc.)
With a company that did a big funding round it‘s very likely that it gets acquired, shut-down, products get sunsetted, API endpoints need to be changed in the next years.
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.
226 comments
[ 0.20 ms ] story [ 249 ms ] threadI 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.
"Unlike AWS Aurora we decided to open source all the changes in Postgres and also send them upstream as well as fully open source our cloud native storage."
Also, at the top right there's a link to the GitHub repo: https://github.com/neondatabase/neon
You can find replies from folks in this thread as well discussing self hosted deployments and you can find an entire discord channel dedicated to that topic here: https://discord.gg/92vNTzKDGp
I'm not associated with Neon and I've never used it before and I certainly don't disagree with your sentiment, but it seems like Neon has gone above and beyond in making sure that workloads could continue to run in the event the company fails and broadly assuaging those concerns.
(Neon engineer)
I could've sworn I closed my Reddit account. I thought neon was meant to be a bit like Git with data, with branches etc, as well as autoscaling and nice stuff like that.
> (Neon DevRel here) [...] However, many production databases won't scale to zero often.
I think a planned consistent message might be best
Neon won't pull the rug from under an active production database by scaling to 0 when there are still active queries, instead it'll scale databases to 0 only after a longer period of inactivity. So production databases are less likely to scale to 0 because they generally are active most of the time, yet Neon does scale to 0 when it's possible and allowed.
If the branches are achieved using a COW file system, how does this part from the blog post work?
> Suppose a developer fat fingers a table or a database out of existence? No problem, move the branch to the second before that event happened.
How can I go back in time arbitrarily here? I would have assumed that you can only go to existing snapshots if the underlying method is a COW file system.
PostgreSQL writes changes to disk using WAL for consistency. Every WAL record is a set of changes to the PostgreSQL data directory (data files, metadata, ...) that need to be persisted together.
Neon indexes this WAL, and restores pages to the right version by replaying all WAL from the previous page snapshot up to the right version, allowing full point-in-time for all persistent tables in the database.
Branching in Neon should be interpreted more like the branches seen in graph theory's trees rather than the featureset exposed by git: the whole history of a Neon project is a unidirected graph with a single path between any two points in the history.
> For instance, would this also work across major PG versions
As for multiple major versions: We currently can handle multiple major versions in different tenants on the same pageserver/safekeeper servers, just not for the user's PostgreSQL instance. Major version upgrades (by way of pg_upgrade) are something we're working on, but that's still quite far down the road.
> afaict, it is just not possible to merge two differently versioned postgres-es
Correct, and AFAIK we don't actually advertise anything related to merging histories. If we do, please do tell where, so we can correct that.
We can branch off the main database to test things out, and periodically reset the branch to its parent.
There are some points where the analogy doesn't quite work, but what should they call it instead?
This blog post has a lot more details: https://neon.tech/blog/get-page-at-lsn
Source code here: https://github.com/neondatabase/autoscaling
I'm wondering what accounts for the difference; is Turso just bleeding money on smaller tiers, etc?
Is this faster / more resilient?
I guess it's just trust. I trust postgres more than I trust sqlite for building big apps.
One last point: I'd look at feature set of both offerings. I suspect the features of the postgres offering to be more conducive to scale.
Take some time to learn about the differences between postgres and sqlite it is good to know about the trade offs.
With Neon you get a postgresql database over a postgres wire format connection.
So if you have an already existing app speaking postgres to a database somewhere, Neon is a drop-in-replacement, while Turso would require adapting to their custom API.
If you are creating a new service, you might need/want to take advantage of e.g postgres extensions [0] for storing geographical data or pg_vector for similarity searches etc. Or you simply need more stringent serialisability promises than what libsql / turso can provide.
But if you just writing something new from scratch and have "simple" demands, I think something like Turso looks cool (and cheap!).
[0]: https://neon.tech/docs/extensions/pg-extensions
> Lots of people have been reaching out to me asking if they should expect our free tier to be around, given recent news.
> Yes, you can expect our free tier to be around.
> The main reason we built a service on SQLite is that we knew we could build the most efficient thing in the market with that. I usually keep these number semi private, but last month Turso had over 20,000 databases under management - in all plans - and our Cloud bill was less then 3.5K USD.
> I sympathize with Planetscale, in the sense that running a company is hard and you sometimes have to make hard choices. But look beyond words, into cost structures and incentives:
> Of course our service is expensive to operate, like any service, but most of it is staffing. We'll never find ourselves in a situation where killing our free tier will make any dent in the profitability of the company.
https://twitter.com/glcst/status/1765466864338034717
They never exceed the limit you set in the number of cpus.
In practice the cost a lot less than max number of cpus * time. Think about area under the curve of cpu(t).
Storage costs can be calculated as something along the lines of:
(Neon engineer)Our storage tech is amazing :)
And written in Rust for extra fun and profit
The only issue I've found with Neon is that to use listen/notify the DB needs to be awake 24/7 which defeats the purpose of serverless.
This is valid. However, many production databases won't scale to zero often. The serverless proposition is still valuable if you factor in the development, test, and staging environments scaling to zero plus our autoscaling that doesn't require downtime or dropped connections.
For guaranteed message delivery, you're probably best of using a messaging system designed with that in mind instead of listen/notify.
(Neon Engineer)
https://news.ycombinator.com/item?id=40039191
Your HN profile doesn’t tell.
Stas Kelvich one of my bosses, and one of the founders of Neon.
We are rethinking this, please stay tuned
By the way, I do want to say that branching is a game changer. The recent usability improvements like graphs/metrics and being able to reset a branch to the state of another one without affecting the endpoint is so nice. We previously had a messy script that took care of creating a new branch, moving endpoints, renaming, deleting, etc.
More fine-grained permissions for users on projects would be my number one ask at this point, but overall, I really appreciate the improvements the Neon team has made in recent months.
This architecture delivers really good safety: Once your transaction commits, the data is already replicated across different AZs, and this is done without there being an S3 request each time. It also means that Neon can deliver features like branching.
(Neon engineer)
I hope it is encrypted on S3 at least? :)
https://neon.tech/docs/introduction/architecture-overview
There is no system of per-project encryption keys though.
Reducing our COGS is very important, and also something that we will be working on. I would definitely reach out to our sales team for a more custom quote.
(Neon engineer)
Either way, if you get big enough (will use more storage + compute), it makes sense to move. I'd be against such platforms as they make changes to Postgres that might make you depend on them.
FWIW, Neon is really "just" Postgres. I can't think of anything Neon specific that would lock you in, other than that we don't support certain kinds of extensions yet. But if you were going to use those extensions, then you probably wouldn't have picked Neon in the first place. I also wouldn't consider that a lock-in. Do you have any examples that you might be aware of in Neon? Postgres compatibility is something that we take very seriously.
(Neon employee)
Congrats to the amazing Neon team on launching serverless Postgres to the world!
(neon product)
(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.
A nice marketing opportunity for Neon/Supabase to get a fix officially released.
Good that they added it now.
(Neon engineer)
Edit: to be more specific, we will have a new calculations similar to how Snowflake does theirs.
Hope that helps!
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)
How many times do you expect to slice it? "For 99% of days this year, 99% of our customers have experienced 99% reliability for 99% of their users, we're 99% sure"? (That's just the long way of saying 95%)
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.
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.
(Neon Postgres engineer)
https://pgug.ee/meetings/06/
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)
We have an SLA in place and haven’t had a single issue so far.
Edit: Love to see several Neon folks in this thread from various parts of the company. It's always good to get insight from engineering, devrel, product, and CEO.
For a simple comparison, let's assume you only use 0.25 vCPU computes and your primary compute runs 24/7 (~750 hours per month) to keep the comparison easy:
1. On the Free plan, you can have the primary running 24/7 plus an additional 20 hours for other branches.
2. On the Launch plan, you can have the primary running 24/7 plus an additional 450 hours for other branches. And of course the 10 GiB storage + other paid features.
Full details at https://neon.tech/docs/introduction/plans
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‘d argue that the most important way to spend the time is on building something customers want and not micro-optimize with shiny database vendor of the week. Get a boring managed Postgres and it‘ll scale for a very very long time, it‘s well understood and if you hit the limit, that‘s a good problem to have and there‘s many solutions for that when the time comes.
My customer profile at the time was mom-and-pop small businesses. Bespoke application development that automated back office work delivered on ~6week timeline.
The size of their tech department was 0.
The goal with the architecture I delivered was to delegate as much as possible below a vendor boundary.
My solution was: Cloudflare workers for compute. R2 for storage. Neon for database. HTML/JS/CSS for the frontend.
Neon wasn’t a micro-optimization. It was the only vendor in town that would own that much of the DB layer’s responsibility (D2 wasn’t prod ready yet).
12months in and so far so good. I’ve had to “come back in” for a total of 30minutes of maintenance when mobile Chrome broke uploading a photo via camera.
Wouldn‘t you want the most boring solution that‘s unlikely to change in the next 5 years for this use case? (AWS etc.)
With a company that did a big funding round it‘s very likely that it gets acquired, shut-down, products get sunsetted, API endpoints need to be changed in the next years.
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.