A late and limited weekly note, focused only on the general availability of Serverless Aurora for MySQL. I was busy with more important, personal, matters last week, and this was the only thing to break through that bubble.

AWS Aurora Serverless

Aurora Serverless was part of the big announcements coming out of the last re:Invent¹, but got a bit overshadowed by some of the other, sexier, news. That’s not to say it isn’t a very interesting release in itself, and now it’s available for everyone².

But what is it really? Well, in a way it’s the next part of the serverless movement. After all, if we can have compute power that is only active when we need it, why not have the same for your database? And while a solution like DynamoDB is great for many things, there are times when a relational database is what you need. However, up until now that still meant that you needed to have your database servers continuously running.

Last year AWS introduced the ability to temporarily turn of RDS instances, though not Aurora ones, and that already helped a bit but it wasn’t a full solution. You still needed to schedule them to come up and things like that. With Aurora Serverless that is now changed, as the only thing you need to define is the minimum and maximum scaling settings.

So, how does this work? Let’s start with a quick background about Aurora. In short, Aurora offers you a shared storage for your data across three Availability Zones. In front of that you can the put one or more instances³, which basically serve as the compute layer you need to access the data. Aurora Serverless keeps this intact, but instead of you defining the actual compute instances these become available when required. You could say that this is similar to a comparison between EC2 and Lambda functions.

There are more details in the announcement, but there is one more part I want to focus on. What’s the point of this? When and where would you use this? Obviously, it depends⁴, but until you’ve done some good performance testing I would recommend using it for non-production environments only. Which is obviously an area where it can be very useful. Especially if you turn off those environments outside of business hours or the compute part there is already serverless.

Some other tidbits you might want to pay attention to. While for now this is only available for Aurora MySQL, the announcement makes it clear that it will show up for Postgres as well at some point. And most importantly, just like with Lambda, there can be a delay after the initial call to an inactive/scaled down Aurora cluster. If it has no active compute instances, these need to be assigned to the cluster and that can take several seconds, if the cluster is paused that can even be up to 25 seconds. Which means that if you have something that is infrequently accessed but requires a quick response⁵ this might not be the solution for you.