AWS Aurora Serverless V2 | Hacker News Reader

AWS Aurora Serverless V2

aws.amazon.com

42 pointseigilsagafos14 comments

I was excited for V2 but honestly my experience with V1 was very subpar and I ended up moving to PlanetScale instead of continuing to work around their frustrating limitations and high costs.

V2 has DOUBLED in price and while you can now adjust it in .5 "ACU" it's dead on arrival for me. Honestly V1 was way too expensive for what you got in my opinion. Having to deal with Dev/QA environments sleeping was a huge PITA (sorry, I'm 1 developer, I can't pay 3x$45/mo, even keeping prod up was expensive). Scaling up was SLOW and often failed, I ended up just scaling up super high before my event that used my product because I was worried it wouldn't scale up automatically. In my testing I always had to stop using the DB for a while before it would finally scale up.

As for my Dev/QA environments, I was able to wake them from sleep when you hit the client app but it would take almost a minute to wake. In order to save money I had those environments sleep after 5 minutes of inactivity. Maybe it would have been better if I raised that to 10-30min but I'd regularly finish writing some server/client code then go to use it and realize the DB went to sleep on me and have to wait on it.

With PlanetScale it's $30/mo and I can have Dev/QA Branches that don't cost me any extra. Not to mention they actually seem to understand the need for things like lots of connections. I had read not great things about Aurora handling a ton of Lambdas connecting to them and so I wrote the first version of my product using their data-api which was a mistake. Since then I've moved to using Primsa as my ORM and you can throw literally a quarter of a million connections at PS without issue [0].

I almost built on top of Aurora Serverless V2 when it was in beta and I'm so glad I didn't and that I found PlanetScale when I did.

[0] https://planetscale.com/blog/planetscale-vs-aws-rds

> While RDS limits connections to 16,000 PlanetScale has been designed to scale upwards of 250,000 connections to a single database. Theoretically we can handle millions of connections-- but 250,000 is a real world number.

This is really interesting, we're also using Prisma, still on Prisma 1 unfortunately. But what has your learning curve for PlanetScale been like? Is there any maintenance or gotchas you have experienced that you didn't realize going into using them?

So far it’s been great overall. You can’t use foreign keys but that’s not a big issue for me (there is an easy work-around for this in Prisma and you just need to remember to add indexes on those columns).

Aside from that nothing is coming to mind. You just change your Prisma file, “npx prisma db push” to update your dev DB branch, and then when you are ready to move environments you just make a pull request to the next branch (like dev->qa).

Very interested to see if this actually ends up saving money for which use cases exactly. Seems very hard to determine that right now. But this is the holy grail I've been looking for if it doesn't end up pulling the firebase problem on you, massive costs out of nowhere or ability to predict how much it will be. I guess that's why they let you set a limit, so it's not unlimited, but even so I wish they could analyze your current usage patterns over a month with the non-serverless aurora product, and then give a price reduction estimate comparison had you been using V2 serverless. Would immediately give a ton of people confidence and create word of mouth buzz on forums that it actually is super promising.

Can someone describe how it's possible to auto-scale the CPUs on a database? How are CPUs effortlessly attached and removed from a running MySQL database?

So, I moved one of our Postgres DBs to Aurora Serverless V2 (for testing). First the process is super ridiculous. Anyways I am quite disappointed. One of the main reasons was their "scaling to 0" for some DBs we get close to none and then really spiky traffic. But they removed that! So, that leaves you with .5 ACUs running no matter what. But that is not great! Its 0.07 per hour, a t3.micro is 0.02 an hour. I was looking for a DB that could scale to 0 cost and then ramp up to handle > 10k requests per seconds.

Very excited to see this in general availability and with Postgres support

Great work Amazon Web Services (AWS)! I am already waiting for V3.... Wish list:

- Pay per transaction (Reads, Writes) + Storage, instead of per resource allocation (some competitors are offering this already).

- No need for VPC, just like DynamoDB does today.

- Multi-region sync replication (no data loss in case a region goes down), but on a per-table base.

- Self-tuning capabilities, like ottertune and postgres.ai

- Unlimited Fast Database Cloning copies for non-production environments (COW)

- Transparent connection pooler (useful when using Lambda)

I thought it would stay in beta forever and I remember it was only MySQL. Might be wrong though. Can't wait to try it to reduce costs.

Does anyone know if Aurora PostgreSQL is a full drop-in replacement for Postgres, or is it "Postgres compatible" but missing some features (like CockroachDB, for example)? I am very interested in this service but some of my projects depend on Postgres-specific features.

Fully Postgres compatible in my experience. As long as you don’t require extensions that AWS doesn’t support. But I believe AWS has the widest array of extensions for Postgres of any cloud provider.

I write my stuff to /dev/null the databaseless database. Lightning fast, more space than S3.

Does /dev/null support sharding? :P https://www.youtube.com/watch?v=HdnDXsqiPYo#t=2m13s

You may be looking for http://webscalesql.org/

Reply on news.ycombinator.com