Originally posted on the 8th Light Blog
Serverless is a borderline buzzword nowadays. Serverless websites! Serverless APIs! Serverless…everything!
And now serverless databases.
Amazon Web Services has their own serverless database offering, which is semi-new, semi-old, depending on the “compatibility version.” This is how you have to use Amazon Aurora, AWS’s database engine, which has both MySQL and PostgreSQL “compatible” flavors to get access to the serverless option. MySQL has had the serverless option for longer than PostgreSQL, but both are now generally available to use and production ready.
They may be ready, but…the question, for anyone looking into changing their database setup, is whether serverless is better and cheaper than a dedicated server.
Thankfully, AWS itself tells you what each use case is for on the new-database dialogue.
There’s the normal one-writer/multiple-readers option, which it says is a “good general-purpose option for most workloads.” It is! For the most part, this is going to be a more cost-effective method for hosting a database. You are going to be paying the same amount of money per day despite usage fluctuations, and there’s no worry over it not being available at a given moment. You pay for a specific CPU/Memory amount, and that doesn’t change during the day.
But…the serverless option is enticing for “intermittent or unpredictable workloads.” Imagine an application that’s only used for a few hours a day, or has extreme spikes in usage and the rest of the time it is not that demanding. You may want to save money by not actually running the app for all the hours in the day when absolutely nothing is using it. Or have it scale up when need be, and then be on a “cheap” tier the rest of the time.
If that’s the case, Amazon Aurora Serverless is right for you! There’s a special group of configuration options it has to account for those types of applications. These settings are under the heading “Capacity Settings.”
Instead of selecting a database “tier” that has specific CPU/memory, you select min/max “capacity units” for your database. Capacity units are basically how much CPU/memory is being allocated to your instance. You are billed by capacity unit usage per hour. Think of it like autoscaling min/max for servers. But there are no servers, just the resource amount. AWS automatically scales the database to the demand, within the range you set in its capacity settings.
The scaling’s a big draw for Amazon Aurora Serverless, but there is another option it offers that can really make it an easy sell. It’s called Pause compute capacity after consecutive minutes of inactivity.
That option is where the cost savings really come into play.
For applications that are only used for certain periods of the day, you can have the capacity units pause, going down to zero, after X period of inactivity, say an hour. So after an hour of nothing being utilized, AWS shuts down the server and you stop being charged for capacity units per hour. You only pay for the database storage, which you were paying for anyway. Even for applications that run throughout the business day, you can get major cost savings by not having the database awake during the night.
There is a caveat for this, though: when coming back to the app after inactivity, there is a slight delay as the database comes back up. In my experience, it takes less than a minute to fully come back and start functioning. For some apps, this may not be tolerable. You don’t have to enable that option if you’re just looking to have a scaling database that can support spikes in traffic but still be “awake” the entire day. In my use case, however, this setup has been fine since my app is used so infrequently. The performance is great when it gets going, and it massively reduced the bill each month. A slight delay on warm-up was worth the cost savings. It’s incredibly flexible.
Flexibility summarizes the entire serverless database proposition. You don’t have to choose if you don’t know for certain. It’ll figure it out based on reality, and you pay for what you use.
Converting to an Amazon Aurora Serverless database is not without cost of conversion or downtime; but for long-term cost reduction and stability it may be worth it, and the right path forward for your application.
Note: I used the PostgreSQL compatible option for the screenshots.