return to table of content

Neon Serverless Postgres is generally available

t1c
23 replies
3h33m

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.

lonerranger
4 replies
3h11m

Neon is so unreliable that they removed the percentages from their status website. A truly bad thing for a data company to do.

tristan957
1 replies
2h59m

They were calculated incorrectly, actually. This is something we are actively working on. We hoped to have it back for GA, but it didn't make it.

(Neon engineer)

Edit: to be more specific, we will have a new calculations similar to how Snowflake does theirs.

throwaway5959
0 replies
2h17m

I’m not sure that’s much better?

shinypokemon
0 replies
2h52m

(Neon DevRel)

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)

nikita
0 replies
1h56m

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.

We will also update the status page soon.

csomar
4 replies
3h14m

I couldn't try it because it had no email sign-up. Which is kind of weird for something that offer a tech (hosting essentially) product.

virtuozzz
1 replies
3h12m

it has an email sign-up

tristan957
0 replies
3h11m

We have an email sign-up now.

mj4e
0 replies
3h10m

(Neon PM) You can use email+password, GitHub, Google or Hasura credentials to sign up at https://console.neon.tech/signup

clarkbw
4 replies
3h25m

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.

(neon empl)

t1c
1 replies
2h27m

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

password4321
0 replies
1h51m

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.

codetrotter
1 replies
3h15m

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.

mj4e
1 replies
3h24m

(Neon PM) saddened to read this if I can help with anything you can reach me directly mike@neon.tech

t1c
0 replies
2h29m

Hi Mike, I appreciate that, but I don't think I see myself using Neon anytime soon, if at all.

shever73
0 replies
1h30m

Another satisfied Neon user here. We migrated our tooling, users and thousands of databases recently and it has just worked.

r3trohack3r
0 replies
2h57m

This has not been my experience.

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.

maccaw
0 replies
3h16m

Fwiw my experience has been the exact opposite. It is by far away, the best serverless database I’ve used.

compootr
0 replies
1h33m

adding on, didn't they also hide the percentages from their status page because it was going down so much?

boomskats
0 replies
1h56m

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.

MentallyRetired
0 replies
3h12m

I've had nothing but good experiences with them.

redrove
10 replies
3h57m

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.

nikita
9 replies
3h50m

(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

nolok
2 replies
3h37m

Hello, not parent

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.

ZeroCool2u
1 replies
3h21m

In the linked article it says:

"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.

adam_gyroscope
0 replies
2h17m

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.

margorczynski
2 replies
3h34m

(Neon ceo) 1. You should try and see the experience

And what would be that "experience"? Bro, it's a managed Postgres instance. From what you've wrote the main points are:

1) It costs less than Aurora (some numbers on that?)

2) It integrates with Vercel (some hobbyist PaaS)

robertlagrant
0 replies
3h28m

Bro, it's a managed Postgres instance

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.

figassis
0 replies
2h5m

Branching would be valuable

lelanthran
1 replies
3h19m

Neon ceo) [...] It scales to 0.

(Neon DevRel here) [...] However, many production databases won't scale to zero often.

I think a planned consistent message might be best

mattashii
0 replies
3h7m

(employee)

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.

bittermandel
0 replies
3h13m

(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.

bilalq
8 replies
3h35m

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.

nikita
4 replies
3h26m

We are currently lumping storage retention history (we store all the history for a period of time so you can time travel) and backups together.

We are rethinking this, please stay tuned

bilalq
3 replies
2h59m

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.

throwaway5959
2 replies
2h13m

I’m confused, are we talking about object storage here? Like $0.023/GB in S3 storage cost?

est31
1 replies
1h44m

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.

(Neon engineer)

leftcenterright
0 replies
40m

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.

I hope it is encrypted on S3 at least? :)

mj4e
0 replies
3h16m

(Neon PM). If you're willing to discuss your project's specifics, contact me directly mike@neon.tech as I'd love to chat.

csomar
0 replies
2h58m

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.

GordonS
0 replies
2h32m

This almost feels like how cloud providers charge excessive fees for excess bandwidth. Storage is cheap, even with replication, especially at Neon scale.

joshstrange
7 replies
3h14m

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.

dewey
4 replies
3h0m

Switching over a company, and especially the database, to a beta product that was not public yet…that‘s brave.

r3trohack3r
2 replies
2h52m

Not OP, but I did the same.

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.

tasubotadas
0 replies
59m

Can you please share your github action for backup on r2?

dewey
0 replies
2h44m

The most important way you can spend your time…

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.

joshstrange
0 replies
2h56m

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.

ksec
1 replies
1h32m

Why switch away from PlanetScale though?

joshstrange
0 replies
1h30m

1 "Database" = 1 Server/Cluster

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.

yawnxyz
6 replies
3h55m

That pricing is quite "less generous" than Turso: https://turso.tech/pricing

I'm wondering what accounts for the difference; is Turso just bleeding money on smaller tiers, etc?

johtso
4 replies
3h54m

Turso is sqlite not postgresql

yawnxyz
3 replies
3h52m

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

Is this faster / more resilient?

nop_slide
0 replies
3h43m

They both could be faster or more resilient depending on your workload and what you want that to mean.

Take some time to learn about the differences between postgres and sqlite it is good to know about the trade offs.

filleokus
0 replies
3h41m

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!).

[0]: https://neon.tech/docs/extensions/pg-extensions

djha-skin
0 replies
3h47m

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.

SwiftyBug
0 replies
3h50m

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.

https://twitter.com/glcst/status/1765466864338034717

mrozbarry
6 replies
3h12m

I'm working with a client on a greenfield project and I picked postgres as the tech stack. For the staging server, I just locally installed postgres, configured it, and it works perfectly fine. On the flip side, I'd rather just focus on code, and if there's a free tier (which neon has), I'd rather shell that off to a service.

So, my question is, what trade offs am I making other than a persistant/local db to off-site (ie probably a degree of speed). Since it's free, does that mean my data might be inspected? I'm under an NDA, and my client would prefer his data stays in-house unless there's a good reason for it not to be.

tristan957
2 replies
3h3m

We do not inspect user data. We don't even connect to user databases, unless given permission to. You can read our privacy policy here: https://neon.tech/privacy-policy.

Neon will never be as fast as a database local on your computer, but performance is always something we are paying attention to.

devjab
1 replies
2h25m

If you’re aiming for EU compliance you’re going to need to host the data within the EU and only have EU staff have any sort of access, like running support on it. Microsoft is exempt from that last bit for some reason, but they are Microsoft so they probably cheat.

Won’t be a lot of EU enterprise that will be capable of using your services without rather strict compliance. Which may or may not be in your interest but you might as well just be up front about it. With the way EU is heading in regards to data protection it may not just be enterprise organisations either by 2025. Those compliance laws are getting stricter and stricter by the day.

tristan957
0 replies
2h0m

We support EU regions. Our sales team is happy to talk more about our data compliance.

mbil
2 replies
3h1m

The free tier gets spun down to idle after five minutes of inactivity. The first request after that usually fails to connect as it takes a few seconds for it to come back up.

tristan957
1 replies
2h51m

Neon cold starts are targeted at just a few hundred milliseconds. Anything on the order of seconds would be a regression in our minds. Obviously this depends on geographical latencies, etc. We are always looking to improve cold starts.

(Neon engineer)

mbil
0 replies
33m

Hmm maybe my application's db pool settings need to be tweaked then. In any case the UX is nice and setup was super easy, thanks!

continuational
6 replies
2h26m

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/

riku_iki
2 replies
33m

For $69/month (Scale)

this also doesn't cover 100% uptime, but only 300h, and you will pay extra for each extra hour.

shinypokemon
1 replies
9m

The Scale plan includes enough hours to run 1 CPU and 4GB of memory for the month.

riku_iki
0 replies
1m

Agree, I looked at wrong plan, sorry for confusion.

shinypokemon
0 replies
1h51m

(Neon DevRel)

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.

hamandcheese
0 replies
1h49m

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.

dustyduster
0 replies
1h50m

$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).

bittermandel
5 replies
3h11m

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

andix
3 replies
2h24m

What's your added value in comparison to using plain Postgres, for example with the CloudnativePG operator for k8s?

bittermandel
2 replies
2h5m

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!

leftcenterright
0 replies
53m

Sounds like a good use case. Do you have any benchmarks or numbers which you could share regarding the performance of database? (especially disk writes and reads)

andix
0 replies
1h35m

Thanks for the explanation! This sounds like the right use case to use something more complex.

I’m always hesitant to add additional technology to the stack if it doesn’t provide a bullet proof benefit. A lot of use cases are perfectly fine with plain postgres, and I’m always fighting against polluting the stack with additional unneeded complexity.

clarkbw
0 replies
3h5m

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.

pier25
4 replies
3h47m

Anyone using it in production?

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.

shinypokemon
2 replies
3h32m

(Neon DevRel here)

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.

pc86
1 replies
3h21m

Is it possible to set the production database to have a minimum scale of 1? So even if it "should" scale to zero it won't?

joshstrange
0 replies
3h16m

Yes, you can set the min/max for scale. I scale down to “.25” as my min.

mj4e
0 replies
3h35m

(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.

kelvich
2 replies
3h13m

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.

k8sToGo
1 replies
3h3m

Who is “we”? Who are you?

Your HN profile doesn’t tell.

mattashii
0 replies
2h53m

(PG Hacker @ Neon)

Stas Kelvich one of my bosses, and one of the founders of Neon.

nikita
0 replies
3h36m

Yes :)

jrklabs_com
4 replies
3h54m

If you have an application that runs 24*7, how do you determine what your costs will be?

nikita
2 replies
3h44m

(Neon ceo)

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).

jmuguy
1 replies
3h27m

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.

nikita
0 replies
3h25m

You will likely save money on Neon. Please reach out to our team (contact sales, support or discord) and we will give you an estimate

mj4e
0 replies
3h40m

(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.

fabian2k
4 replies
3h56m

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.

mattashii
1 replies
3h53m

(Postgres hacker @ Neon)

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.

leftcenterright
0 replies
34m

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

sakras
0 replies
3h51m

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).

This blog post has a lot more details: https://neon.tech/blog/get-page-at-lsn

sakras
3 replies
3h55m

I'm an engineer at Neon, happy to answer any questions

leftcenterright
1 replies
44m

I would appreciate some details on the implementation of isolation for multi-tenancy. Are the worker nodes shared?

sakras
0 replies
19m

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.

Source code here: https://github.com/neondatabase/autoscaling

tristan957
0 replies
3h18m

Same here!

pc86
3 replies
3h24m

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.

mj4e
2 replies
3h19m

(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.

pc86
1 replies
3h18m

Thanks! So that 300h of compute is for other branches? Still 24/7 for primary compute on Launch?

mj4e
0 replies
2h57m

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.

Full details at https://neon.tech/docs/introduction/plans

ddorian43
3 replies
3h44m

Will there be any effort to support self hosting open source (releases, docs, support?), instead of just "source code available"?

nikita
2 replies
3h40m

Please join our discord a number of people are doing that and the community is helping out.

herpdyderp
1 replies
3h22m

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.

tristan957
0 replies
3h15m

Especially now that Discord will be displaying ads.

(Neon Engineer)

c-fe
3 replies
3h33m

I have used Cloudflare D1 before - how does Neon compare to D1?

cpursley
2 replies
3h20m

Is D1 Postgres?

sgammon
0 replies
3h10m

D1 is sqlite but it's serverless, so the two are comparable on that basis

c-fe
0 replies
3h11m

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!

aargh_aargh
3 replies
2h52m

Reading the pitch and this solves all of the problems I don't have (as a developer and operator of services that don't need to scale to millions of users). How often do you need to clone/restore whole databases, really? But I may be misunderstanding the pitch.

mj4e
2 replies
2h37m

(Neon PM) instant branching in a development workflow because it's like git but for your database. You can develop or test against an exact copy of production without the risks of testing on production. Autoscaling is useful if the load on your datbase varies (you can save money, even if your app isn't serving millions of users).

neeleshs
0 replies
1h30m

This is very cool for troubleshooting in production. Testing/developing against a production copy is a no-no, if I'm hosting my customer's data.

figassis
0 replies
1h59m

Until you start firing emails and texts to your production customers :-)

That aside, I think Neon is pretty cool. I will wait some time to see how stable a service it is, whether price hikes happen often, or whether VC money destroys it.

I think Autora for me is too pricey, but I settled for self hosting PG on Hetzner. I'm there bc Hetzner has been stable for me for years. What I fear the most is having to migrate a db off of some service bc I stopped being their target audience. I know this sucks for startups trying to make it but a risk is a risk. I'll wait and see.

nottorp
2 replies
2h48m

What's a serverless postgres?

Does it mean a postgres server hosted by Neon and you basically pay them for administration?

letmeinhere
1 replies
2h41m

I think it usually means that it's fully queryable by serverless functions, usually via atomic HTTP API calls, and often without network restrictions.

letmeinhere
0 replies
2h37m

But in this case it seems to be referring to the database itself, and the ability to scale to and from zero resources on demand.

khalidx
2 replies
3h57m

The market timing of this ~1 day (same day?) after Supabase GA? Both are good platforms though.

brospars
1 replies
3h37m

This cannot be a coincidence

sakras
0 replies
3h33m

(Neon engineer) It is a coincidence :) I had to confirm internally too.

doublerabbit
2 replies
2h49m

Postgres continues to hold its position as one of the most popular developer databases ever created.

Not bashing Postgres, however that statement is an overstatement. Postgres was a "it exists" database back in the early 2000's.

All the scripts my scripts kiddie paws could get on were always orientated towards MySQL.

Uploading .php3 files on 56k were my teenagers eyes of fun.

makoz
1 replies
2h37m

Disclaimer work at AWS.

Postgres was a "it exists" database back in the early 2000's.

If we're really nitpicking it's not saying Postgres is the most popular database since the early 2000's. If you base it of off install counts as the metric, I would assume the statement is true since I'd think it's either Postgres or MySQL today.

stemc43
1 replies
3h52m

ad on hackernews?

sgammon
0 replies
3h9m

Everyone shows off their cool work on Hckrnews

rohan_
1 replies
3h50m

Given this is serverless - can this scale indefinitely? Asking both in terms of storage and compute.

nikita
0 replies
3h48m

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.

mehulashah
1 replies
3h48m

Congratulations! Nice job, Neon team. The most remarkable part of the service is the forking history in storage for a database. So fun.

nikita
0 replies
3h42m

(Neon ceo)

Our storage tech is amazing :)

And written in Rust for extra fun and profit

gritzko
1 replies
2h32m

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.

nikita
0 replies
2h29m

Merging is a tricky one for operational databases. We think merging schemas is a useful feature. Merging data is likely not. The feature is coming!

amanda99
1 replies
46m

Does it support extensions like PostGIS?

ahmadrosid
1 replies
3h35m

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!

clarkbw
0 replies
3h21m

Thank you! Can you tell me more about the stack you're using? [pure curiosity]

(neon product)

WuxiFingerHold
1 replies
22m

As far as I know Neon has no filesystem cache, which is the most important performance enhancer for Postgres. As here are many using Neon already in production: Does anyone can comment on the performance for large databases (a couple of tables with around 100 million rows) compared to RDS / Supabase / other hosted service? I can imagine that it is substantially slower. But would be happy to be surprised, if not. Or to learn how Neon compensates the missing filesystem cache.

sakras
0 replies
14m

Neon engineer here. We implemented our own local cache between the pageserver and Postgres (called LFC). It compensates for the lack of a normal file system cache, and scales up with the rest of the autoscaling infrastructure.

ForHackernews
1 replies
2h30m

Is this actually Postgres, or is it some other database that aims to be compatible with the PG wire protocol?

mj4e
0 replies
1h16m

It’s Postgres.

virtuozzz
0 replies
3h58m

Congrats, Neon!

tasubotadas
0 replies
52m

How it compares against supabase?

smallshen
0 replies
2h46m

Is it possible to self host neon? any docs related to that?

sgammon
0 replies
3h12m

I tried Neon for our startup but ended up going with Planetscale. The stability guarantees seemed weak and still scare me. I would be happy to take another look, but I've had no problems with Vitess, it has been a dream. congrats on your guys' launch to GA.

notamy
0 replies
2h41m

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.

nickzelei
0 replies
3h55m

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.

indymike
0 replies
2h3m

The name Neon is very confusing as KDE uses that name for it's Linux Distribution and has for quite some time (at least 2017).

hickstoor
0 replies
3h59m

Yea it’s generally available

hhh
0 replies
2h56m

I have been using Neon for some time now, and have quite liked it.

cpursley
0 replies
3h39m

Cool tech aside, setting up a database in neon is just so easy. It's my default now - especially after releasing replication.

clarkbw
0 replies
2h37m

(neon product)

hey all, i've only been with neon for a very short time but i'm super excited to be here because i believe neon can deliver an amazing developer experience that databases have been lacking. while we are simply postgres on top the neon platform is something special that unlocks a lot of new possibilities.

this ga is simply marking readiness for the platform and the team that has been building it. there's a lot more to do going forward.

as we're looking forward, post-GA, i'd love to hear what you think neon needs to focus on next. here's what i'm seeing so far: - improved gh actions integration - more extensions - better developer extension support - autoscaling communications - metrics / logs integrations

what else?

ashutoshw3
0 replies
2h50m

I am one of the super happy customer of neon. this definitely deserved an upvote on PH (https://www.producthunt.com/posts/neon-8)

I have been using it for more than a year now and I never had any kind of issues with it (except for the recent price change)

anentropic
0 replies
2h31m

This looks awesome (wish I had these features for MySQL on my current project...)

Are there any resources for IaC, e.g. terraform provider etc?

amluto
0 replies
2h39m

Have you considered publishing pricing for larger databases? It would be interesting to know whether the offering would be useful at sizes not covered by the listed tiers.

edit: given the headline feature of infinite PITR capability, knowing the price tag could be quite important. Especially if purging old data isn’t supported (is it?)

ametrau
0 replies
3h3m

How many of these comments are sock puppets?

PeterZaitsev
0 replies
3h52m

Congrats! It has been quite the journey!

CuriouslyC
0 replies
2h35m

Neat idea, but the stability and assurance of RDS is pretty compelling and migrating databases is pretty much the worst in my experience, even big services like Azure can have unexpected database issues that burn time and money.

Also, custom postgres implementations are a bit scary from a performance tuning perspective.

AYBABTME
0 replies
3h34m

Congrats on reaching GA!