Making Sense of Serverless SQL
There is no shortage of options when you need to create a managed instance of Azure SQL. Earlier this year, Microsoft introduced a new option they call Azure SQL Database Serverless. Let me give you some details about the serverless option so you can decide if serverless is the right Azure SQL for your project. This new option has some specific use cases in mind.
Before serverless came along, all the assorted flavors of Azure SQL assumed you’d need a database that was online and ready to go every minute of the day. But, not every database is front and center in the business. I worked on a recent project, for example, where the database would only see action for about 4 hours a day, and only on Mondays and Wednesdays.
SQL serverless is for those types of databases that are not heavily utilized and experience periods of complete inactivity. Think about my scenario with the Monday / Wednesday database. I could provision an instance of Azure SQL and scale the database DTUs up and down so I’m not paying for DTUs I don’t use 5 days of the week. But, it would be even better if Azure did the scaling for me, and only charged me for what I was using. I’m happy to pay for the secure storage of data the entire week. But, if my database is only using 8 hours of compute power every week, I’d like to pay nothing for the other 160 hours. This is what serverless SQL can give me.
Configuring SQL Serverless
The image below captures the principal elements of SQL Serverless configuration. The screen capture is from an Azure SQL Server setup in the Azure portal.
The serverless option is only available under the vCore purchasing model. What you’ll pay for serverless will depend on how much memory and how many processors your database uses, as well as how much storage the database requires. To control the compute cost, you set the min and max number of cores. You can go as small as 0.5 and, thanks to a recent updates, scale to a max of 16. The available memory is correlated to the number of cores you use and starts at 3GB. If you max out on cores at 16, you’ll have 48GB of memory available. Azure will use these parameters to give your database the cores and memory needed to handle the current load.
Storage is cheap, as usual. You’ll pay about $0.12 a month for every GB. Compute is just under $0.27 per vCore per hour. If your database uses 1 processor for an entire day, that’s under $7 for the day. However, if the database is inactive you can pause the database and pay nothing for the compute power.
You can pause a database programmatically, or manually in the portal. You can also allow Azure to auto-pause a database. In the previous screen capture, you can see the auto-pause feature is enabled and Azure will pause the database if there is no activity for one hour. One hour is the minimum setting here, currently.
You’ll be happy when Azure auto-pauses your inactive database and drops your compute costs to zero. However, the next client or app to connect to the database might not be happy waiting for the database to resume. There is a slight delay when resuming a database.
You’ll also want to be aware that your database is operating in an environment where Azure will actively reclaim resources when the resources are not being used. This means, for example, that your SQL Server cache size will drop when the database utilization is low.
These slow starts and cache evictions will have performance implications for your database. If performance is critical to your database users, you might need to stick with a provisioned pricing model instead of going serverless. As always, the best way to know if you can live with the serverless caveats is to do some testing with a realistic workload.
SQL serverless gives us an inexpensive pricing option for SQL Server in the cloud. If your database sees sporadic activity and goes through periods of total silence, then the cost savings might far outweigh the small performance penalties.