When I hear the term serverless my mind gets confused. How can a database exist without a server? Azure is a cloud platform, is my database just floating in the air? No, I am not really thinking that, but still the word serverless can be hard to understand. So, let’s walk through what it is.
Serverless is a term commonly used for function as a service patterns like Amazon Lambda, or Azure Functions, where you have a piece of code that is called and executed without you deploying any infrastructure. Azure Logic Apps are another version of this—a program that exists to do a thing (say create a user and send them an email) without any notion of what computer it executes on. Serverless in terms of Azure SQL Database is a bit of a misnomer because you still have a logical server to which you connect.
Within the Azure SQL Database service, serverless is a type of deployment in the general-purpose service tier for a single database that allows for autoscaling and auto-pausing. It gives you the ability to manage the resources the service uses, and costs associated with your SQL Database, which in turn can save you a lot of money.
Traditionally, when using Azure SQL Databases, you provision a specific compute tier which provides dedicated resources with fixed costs billed on an hourly rate. This is great when your database has consistent usage patterns, using elastic pools or have average higher utilization. But what if your utilization fluctuates? What if you could save money when utilization is lower? That’s where serverless comes in. When you have those less active workloads serverless will scale back your compute tier and even optionally autopause resources and not charge you for non-use. You can imagine how much this can lower your Azure SQL budget. In addition, serverless costs are based on per second usage verses per hour, so every second you are paused you are saving money. Note, storage is still billed during the pause time since your data is still consuming storage, which is something to keep in mind. Additionally, you should note that serverless costs more per second than Azure SQL Database does—so if you have a constant workload that is relatively high, your costs may be higher than for a standard database. As always it is important to understand your workload before moving to serverless, but it’s fantastic for most dev and test environments.
If the database id paused it, does not mean your database is not available to your users. Serverless continually monitors for logins and activity at the gateway for your database. When the next activity occurs the database automatically resumes at the proper compute. Autopausing requires two things to occur before a pause is initiated. One there must be zero sessions and two the CPU must equal zero for user workload running in the user pool. To help give you a little control over this there is a performance configuration called autopause delay which allows you to set the evaluation time period of inactivity before an autopause will occur.
What if your workload varies throughout the day therefore causing a wide range of consumption of compute resources? Serverless can help with that too. When setting up a serverless SQL Database you will configure a minimum vCores and a maximum vCores. The SQL Database will automatically operate within this range for scaling on demand. This illustrates an automatic cost saving mechanism without having to manually scale your database each time you need to increase or decrease your compute needs.
This was a very simple explanation of what Azure SQL Database Serverless is. I hope this clears up any confusion you might have had. Once I realized it just means you can autoscale and are not set to a pre-provisioned compute tier, it was simple to understand.