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.
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
Branching the whole database (data included) seems really great. Congrats!<p>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:
<a href="https://www.hetzner.com/dedicated-rootserver/matrix-ax/" rel="nofollow">https://www.hetzner.com/dedicated-rootserver/matrix-ax/</a>
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.<p>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’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.
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.
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.
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.<p>Congrats to the amazing Neon team on launching serverless Postgres to the world!
Anyone using it in production?<p>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.
Is it a coincidence supabase went GA 2 hours before this? Not being snarky, genuinely curious.<p><a href="https://news.ycombinator.com/item?id=40039191">https://news.ycombinator.com/item?id=40039191</a>
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.
(neon product)<p>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.<p>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.<p>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<p>what else?
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.
I want to use this as a chance to bring attention to a GitHub issue that I think would help reduce friction for Neon:<p><a href="https://github.com/neondatabase/neon/issues/4989">https://github.com/neondatabase/neon/issues/4989</a><p>If the Neon driver were to allow us to easily pass in a localhost connection, the development and test experience would be easier. Perhaps Neon could swap to something like this internally: <a href="https://github.com/porsager/postgres">https://github.com/porsager/postgres</a>.<p>Having run a local dev environment connected to Neon and tests connected to Neon got in our way of adoption. We'd prefer to develop and run tests against a regular Postgres localhost database.<p>To the PMs of Neon, put yourself in the shoes of a new developer thinking of giving Neon a try. What changes will I have to make to my code and my development workflow?
The technology is interesting but the billing doesn't convince me. I don't feel that I can scale storage easier with Neon than using just a bigger server with plain Postgresql.
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.<p>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.
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.
Neon seems really great to me, but I wish I could easily run it locally via Kubernetes. I know there are some projects out there[0] but they are all supported by 3rd parties and things like branching and other features don't appear to be supported.<p>I'd love to be able to just use a helm chart to have Neon in my homelab.<p>[0] <a href="https://github.com/itsbalamurali/neon-operator">https://github.com/itsbalamurali/neon-operator</a>
> Postgres continues to hold its position as one of the most popular developer databases ever created.<p>Not bashing Postgres, however that statement is an overstatement. Postgres was a "it exists" database back in the early 2000's.<p>All the scripts my scripts kiddie paws could get on were always orientated towards MySQL.<p>Uploading .php3 files on 56k were my teenagers eyes of fun.
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.<p>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?)
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.
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.
That pricing is quite "less generous" than Turso: <a href="https://turso.tech/pricing" rel="nofollow">https://turso.tech/pricing</a><p>I'm wondering what accounts for the difference; is Turso just bleeding money on smaller tiers, etc?
I doubt I’ll ever use Neon again after they had our production database go down several times over just a couple of months Q4 last year. We got tired of the downtime during an incident and we were able to spin up a Supabase PG instance and switch over to it faster than Neon could resolve the incident. It wound up taking them days to resolve it fully. They then increased the prices significantly about a month later. Given that it’s only been four months since these issues, I don’t think that they are serious people in the slightest and don’t trust them with a production database.
I don't get how this achieves point in time recovery? I assume I'm misunderstanding some fundamental part here.<p>If the branches are achieved using a COW file system, how does this part from the blog post work?<p>> 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.<p>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.
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.<p>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.
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.<p>Also, custom postgres implementations are a bit scary from a performance tuning perspective.
Congrats to Neon on the generally available status. Big vote of confidence. I've looked around and Neon is the only serverless Postgres I’ve seen that provides copy-on-write branching. Every other managed service has some significant seeding limitation when one looks at the details.