The term "serverless" is so confusing if to me. I had settled on "scale to zero" as my chosen definition for it, because it was the only definition that truly made sense to me and that I very strongly valued. Apparently AWS don't think it means that. I guess it just means "you'll never have to SSH in and upgrade anything"? The other thing that surprises me here is that one of AWS's biggest selling points is how rarel…
Serverless is a paradigm where you pay for capacity, not for a specific number of instances. It's extending "cattle, not pets" beyond VMs to databases. In theory it provides better incentives for both parties: Customers don't have to pick instance size, etc. to try and accomodate their workload. They can buy throughput, etc. in fractions of an actual instance. They can look at their quota usage to determine whether t…
AWS cancels serverless Postgres service that scales to zero
21–30 of 101 posts
Re: AWS cancels serverless Postgres service that scales to zero
#22Re: AWS cancels serverless Postgres service that scales to zero
#23I learned the expensive wya that Aurora Serverless v2 does not, in fact, scale down to 0 when I created three instances for a few days when I was testing out configuration changes. It ended up costing us $300.
Re: AWS cancels serverless Postgres service that scales to zero
#24This year I started to run into some issue with PS mainly around their plans changing (went from pay for reads/writes/storage to pay for compute/storage). Yes, yes, I know they still offer the $30/mo plan but it's billed as "Read/write-based billing for lower-traffic applications" and they dropped all mentions of auto-scaling. That coupled with them sleeping your non-prod DB branches (no auto-wakeup, you had to use the API or console) even after saying that was a feature of the original $30 plan rubbed me the wrong way. Eventually the costs (for what I was getting) were way too out of whack. My app is single-tenant (love it or hate it, it's what it is) so for each customer I was paying $30/mo even though this is event-based software (like in-person, physical events that happen once a year) so for most the year the DB sat there and did nothing.
Given all that I looked into Neon [1] (which I had heard of here on HN, but PS support suggested them, kudos to them for recommending a competitor, I always liked their support/staff) and while going from MySQL to Postgres wasn't painless it was way easier than I had anticipated. It was one of the few times Prisma "just worked", I don't think I'd use it again though, that DB engine is so heavy especially in a lambda. I just switched over fully last week to Neon and things seem to have gone smoothly. I can now run multiple databases on the same shared compute and it scales to 0. In fact it's scale up time is absurdly fast, the DB will "wake up" on it's own when you connect to it and unlike AWS Aurora Serverless v1 it comes up in seconds instead of 30-60+ so you don't even have to account for it. With AWS I had to have something poll the backend waiting to see if the DB was awake yet, to fire off my requests, if it was asleep. With Neon I don't even consider it, the first requests just take an extra second or two if that.
I don't have any ill will towards PlanetScale and I quite enjoyed their product for almost the whole time I used it. Also their support is very responsive and I loved the branching/merging features (I'll miss those but zero-downtime migrations aren't required for my use-case, just nice to have). In fact if I had written my app to be multi-tenant then I'd probably still be on them since I could just scale up to one of their higher plans. It does seem like Neon is significantly (for me/my workload) cheaper for more compute, I had queries taking _forever_ on PS that come back in a second or less on Neon all while paying less.
All that said, I _highly_ recommend checking out Neon if you need "serverless" hosting for Postgres that scales to 0.
Re: AWS cancels serverless Postgres service that scales to zero
#25Honest question, why not just use dynamodb? If I'm already mostly server less and AWS, dynamodb seems like a natural choice for a persistent store in a world where cost and zero-scaling is important.
Re: AWS cancels serverless Postgres service that scales to zero
#26So if I understand correctly, we're (economically) back at the classic model of continuously running a db in a process, right?
Re: AWS cancels serverless Postgres service that scales to zero
#27The term "serverless" is so confusing if to me. I had settled on "scale to zero" as my chosen definition for it, because it was the only definition that truly made sense to me and that I very strongly valued. Apparently AWS don't think it means that. I guess it just means "you'll never have to SSH in and upgrade anything"? The other thing that surprises me here is that one of AWS's biggest selling points is how rarel…
To me that is just "managed". I agree, serverless means scale to 0 (compute and costs). I'm so glad I left AWS Aurora Serverless after how much I disliked v1 and never considered v2. If I was still stuck on them my costs would double or more for my dev/qa environments (which I had scale to 0).
Re: AWS cancels serverless Postgres service that scales to zero
#28Scaling to zero is tricky. In order to make it work you need to
1. Separate storage and compute which aurora has done
2. Have a proxy between the user and an actual VM in which you host Postgres
3. Spin up this VM after authenticating a connection, stand up Postgres inside the VM and run the query
You need to do all that very quickly- ideally in a couple hundred ms. This can only be accomplished with having a warm pool of VM or having extremely fast microVMs like firecracker.
I believe AWS aurora just uses ec2 and that’s why scale to 0 is turned off
Re: AWS cancels serverless Postgres service that scales to zero
#29I guess a good opportunity for someone to build a good alternative. Although it's hard to get it right because if you scale to 0 people will complain about latency and if you don't it's not really serverless.
Re: AWS cancels serverless Postgres service that scales to zero
#30I guess a good opportunity for someone to build a good alternative. Although it's hard to get it right because if you scale to 0 people will complain about latency and if you don't it's not really serverless.