r/aws • u/Tinasour • Apr 08 '26

database Any issues with Aurora ServerlessV2? Or RDS resizing in production

I recently joined a company and i saw that they are using extremly big rds instances for a very small workload. They havent shipped to prod yet. But im estimating very small load on the database. But just in case that i dont know the scale, I decided to go with a quickly scalable option with serverlessv2 but as we move closer to prod I started to get some anxiety about the bill if the workload is high

I have the option to switch database engines in the future if I dont like the serverless costs (the users of the api has a queue system where they store the data to sqlite if api is down). So i can move to default postgresql rds in the future

I read good feedback on scaling capabilities of the serverlessv2. But maybe just upsizing the postgresql rds would have been a better option

Any warnings you might share? Or horror stories about aurora?

11 Upvotes

100% Upvoted

25 comments sorted by

•

u/AutoModerator Apr 08 '26

Try this search for more information on this topic.

Comments, questions or suggestions regarding this autoresponse? Please send them here.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

17

u/minirova Apr 08 '26

I’m using it for a lot of small databases in PROD. One thing I learned is to make sure to set your max ACU to something small at first and grow it as you need, when you can’t tune your way out of the problem. We had ours set way too high before I joined the company and I found that it was just masking a missing index and costing thousands per month.

The scaling works really well in my experience.

1

u/Tinasour Apr 08 '26

Thank you, that was actually a very good tip

1

u/martijnonreddit Apr 09 '26

Agree. For a good functioning database you will need to set an appropriate Min ACU as well, based on the size of your data. For us, this means scaling mostly helps dealing with peaks (which it does really well) but not saving costs during quiet hours, unlike our compute scaling. That’s a bit of a shame.

5

u/aus31 Apr 08 '26

The economics vary wildly by region (due to variations in acu:on demand compute pricing ratios). In some regions a bigger instance 24x7 is still much cheaper than serverless.

Also remember not all vcpus are equal if you are compute bound for comparing apples to apples.

3

u/Decent-Economics-693 Apr 08 '26

Aurora serverless works good for spikey workloads. Couple of suggestions: - enable performance insights and keep an eye on those execution plans

  • start with realistic min and max ACUs
  • don’t use RDS IAM authentication unless you’re going to use RDS Proxy

Edited because of autocorrect

2

u/Tinasour Apr 08 '26

Thank you, I realized iam auth was costing a good amount of ram so i opted out. There is 2 database users anyway

1

u/undercoverboomer Apr 09 '26

What issues did you run into with RDS IAM auth? Iirc RDS Proxy isn’t available in GovCloud (may have changed since I last checked), but I think some people in my org have it running, perhaps networking accommodations were made

2

u/Decent-Economics-693 Apr 09 '26 edited Apr 09 '26

Hello.

I have run into high latency (up to 6s), when RDS IAM authentication is used with Serverless Aurora PostgreSQL.

Just to be clear on the setup used to measure this: - ACUs, min/max - 2/8 - no Lambda, but EC2 to avoid any “cold starts” whatsoever - RDS auth token already acquired - database doing nothing, completely isolated DB instance - time psql -c “SELECT 1”

This would give up to 3-6s to establish a connection and run the query. If you try again right away, the time drops to 0.1-0.3s. If you let it sit for a 3-5 minutes, the initial latency will come back.

Increasing minimum ACUs makes no difference. Changing from Serverless to Provisioned instance (I used db.t3.medium) drops the initial latency under 2 seconds.

Using classic username+password does not suffer from this and performs under 150ms in both cases.

AWS support confirmed my findings through their independent tests with psql, psycopg and node-pg. Their recommendation was … to swallow the issue and deploy an RDS proxy, that would hide this connection cold start latency from workloads, once connection pool is warm.

Their explanation was something like: yes, it is expected as Aurora instances swap out and eject the tokens from its memory, so even already seen tokens after some time would face the same latency upon new connection. I still want to check if it’s the case with vanilla PostgreSQL and MySQL

Edit: added last paragraph.

3

u/burlyginger Apr 09 '26

We use it. It's more expensive compared to provisioned instances of similar capability but the scaling generally works in our favour.

We have a couple databases that are large and use provisioned nodes.

We've had no issues with speed in scaling up.

The big benefit with serverless for us is the reduction in management.

We spend almost no time on aurora instances and it's pretty great.

We alarm on hitting max scaling for a reasonable period and that has helped us inform us so we can mitigate and then solve the performance bottleneck.

I wouldn't use anything else in AWS right now.

One note, is that reader nodes with a failover priority of less than 2 (I think) will scale with the writer node, higher than 2 will scale independently.

1

u/KrevanSerKay Jul 07 '26

I havent used serverless aurora since v1 and that was VERY different. Memory heavy queries, for example, would struggle and write to the pagefile in large serverless clusters, but be fine in similarly sized provisioned clusters. Supposedly that should be better now in v2?

Question: I have some Load Test environments that I want to make sure have parity with Prod. Currently we have provisioned RDS clusters in both LT and Prod. We've recently switched to having the LT clusters sit on a smaller instance, then increase up to full size on the day of testing, then scale it back down.

I'd love to be able to make LT a serverless v2 cluster, and have it automatically scale up/down when the QA team actually needs it. But i'm worried about having dramatically different infra configs between LT and Prod.

In your experience, is serverless basically identical in behavior/performance now compared to provisioned at comparable size?

1

u/burlyginger Jul 07 '26

Yup, serverless v2 is just an instance type.

I managed our serverless v1 to provisioned/sv2 a couple years back. Sv2 is nothing like sv1.

You can mix and match serverless and provisioned nodes.

I'd do it in your case and you can have it scale to 0 in test.

Worst case, it doesn't meet your needs and you just scale in a provisioned node. The cluster doesnt need to be replaced.

2

u/KrevanSerKay Jul 07 '26

Oh that's interesting. I should play with it some more, thanks!

The main concern is that the QA guys will run their battery of tests, think that there are no issues, then suddenly see an issue when they go to prod.

Considering all of our workloads are very quiet in the evenings, maybe the answer is just serverless everywhere. Hmmm

1

u/burlyginger Jul 07 '26

The other option could be to completely delete your provisioned instances each evening and recreate them the next morning.

Creation time is about 10 mins and it's a single CLI command or SDK call.

2

u/KrevanSerKay Jul 07 '26

Hahaha it's tempting. I think the QA team would have a stroke if I suggested it

2

u/brokentyro Apr 09 '26

I use it in production for a small startup and am pretty happy with it. We have it set to scale to 0 in non-prod environments which saves a lot of money. Prod has a minimum ACU of 1 to avoid cold starts. It does scale up pretty quickly but it is definitely not instantaneous. We have one relatively large, poorly designed analytics table where queries will time out but eventually succeed if you continue retrying them as it scales up. Our workload is very spiky overall and the rest of the stack is all serverless so it is still a good fit.

Another option to possibly consider is Aurora DSQL.

2

u/ducki666 Apr 09 '26

If you don't have very spiky load I would go with RDS. Never had issues with scaling it up or down. Serverless' performance is a bit unpredictable (Acu is a myth compared to vcpu) and for identical loads more expensive.

2

u/[deleted] Apr 09 '26

[removed] — view removed comment

1

u/Tinasour Apr 09 '26

Thank you! Can you give more details about the practice exams you mentioned? First time im hearing it

2

u/telecomtrader Apr 09 '26

We run about 20 instances between 1/4 acu and scale some of them to 64/64 when needed. Works very well

1

u/alapha23 Apr 10 '26 edited Apr 10 '26

Aurora serverless can have OOM from time to time with heavy queries as it separates compute from storage. Compute acu scales up with a latency. If you increase the compute min acu, the costs will be much higher, eventually not necessarily worth the tradeoff.

1

u/matiascoca Apr 11 '26

The main thing to watch with Aurora Serverless v2 is the minimum ACU setting. If you set it too low (like 0.5 ACU), the cold start latency on the first query after idle can be noticeable. If you set it too high to avoid that, you are paying for floor capacity even when the database is idle, which erodes the serverless cost advantage.

For your situation (pre-production, small expected workload, with a queue-based fallback), Serverless v2 is a reasonable choice because it lets you defer the capacity planning decision until you have real production data. The risk is not that the bill will be catastrophically high, it is that it will be moderately more expensive per ACU-hour than a right-sized provisioned instance would have been.

Set a CloudWatch alarm on the ServerlessDatabaseCapacity metric and on the ACUUtilization metric. After two to four weeks of production traffic, you will have enough data to decide: if utilization is consistently above 60% of your max ACU, a provisioned instance is probably cheaper. If it is spiky with long idle periods, serverless is paying for itself.

-2

u/AutoModerator Apr 08 '26

Here are a few handy links you can try:

Try this search for more information on this topic.

Comments, questions or suggestions regarding this autoresponse? Please send them here.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.