Overview of Azure SQL Database Serverless

Public cloud offers a wide range of benefits, including scalability, agility, and on-demand resource provisioning. While these benefits apply to majority of cloud services, they are most apparent in the context of serverless computing. Traditionally, this type of functionality was applicable to stateless workloads, but there is a growing number of scenarios that involve stateful services. Azure SQL Database is one of more recent examples of this trend. In this article, you will learn about the characteristics and use cases of the Azure SQL Database serverless tier.

As of December 2019, the serverless tier of Azure SQL Database is available exclusively with the vCore based purchasing model (no support for the model based on Database Transaction Units) in the General-Purpose tier on Generation 5 hardware.

In order to create a serverless Azure SQL Database instance, as part of the provisioning process, you need to specify three additional database parameters that determine its serverless characteristics. The first two are, respectively, the minimum and the maximum number of vCores, which indirectly imply the amount of memory and IO resources available to the database engine. Your selection of maximum vCores can range from 1 to 16 (which correspond to GP_S_Gen5_1 and GP_S_Gen5_16, respectively) and has direct impact on database scalability. The minimum number of vCores has the default value of 0.5. The third parameter is autopause delay, which can vary between 1 hour and 7 days, with 1-hour increments. To disable autopause altogether, you can set the parameter value to -1.

Besides scalability, these parameters also affect the cost and responsiveness of the database. If the database utilization falls below the minimum vCores threshold but it is being actively used, the charges reflect the pricing associated with the minimum vCore level. On the other hand, if the number of sessions and CPU utilization for user workload drop to zero for longer than the time of the autopause delay, then the database is automatically paused. At that point, the cost of the database is based exclusively on its size, without any compute charges. Note that the compute billing granularity is per second, unlike the charges for the traditional Azure SQL Database provisioned compute tiers, calculated on the per hour basis.

A paused database is restarted in response to a number of events, including database logins, creating a database copy, synchronization between the hub and member databases in the SQL Data Sync scenarios, modification of its configuration parameters such as threat detection (including server level changes) sensitivity labels, and tags, as well as viewing or updating the auditing policy, masking rules, transparent data encryption settings, and query store settings. Altering the serverless characteristics (max vCores, min vCores, and autopause delay) will also result in restarting a paused database.

It is important to note that the restart is not immediate but instead is a subject to a delay, expected to take about one minute. Autopause, on the other hand, might take between one and ten minutes. Autoscaling to accommodate increased resource demand might take a few minutes. In addition, while the database remains online during scaling, existing connections are dropped towards the end of that operation.

Effectively, you should carefully consider suitability of Azure SQL Database Serverless in your particular business scenario. Workloads using such databases should be able to gracefully handle timeouts and database availability errors (such as the error 40613 generated when attempting to log on to a paused database). In addition, the database-bound applications and their users must be willing to tolerate delays in the database response time, corresponding to the warm-up time following idle usage periods, as well as occasional disconnects during scaling actions. Another consideration is the potential cost benefit, which will be most apparent in case of individual databases with highly variable and unpredictable usage patterns, which include extensive periods of inactivity.

You also need to keep in mind that autopausing is not available in cases where the database is configured for geo-replication or long-term backup retention, as well as for sync databases that are part of the SQL Data Sync hierarchy or databases that host Azure SQL Database elastic jobs. Furthermore, remember that databases in the serverless tier tend to be affected more significantly than their provisioned counterparts by memory and cache reclaim operations.

To create an Azure SQL Database instance in the serverless tier, you can use any existing deployment method, including the Azure portal, Azure Resource Manager templates, or Azure PowerShell. It is also possible to move a database between the provisioned compute tier and the serverless tier.

# # #

See All Articles by Marcin Policht

Marcin Policht
Marcin Policht
Being a long time reader, I'm proud to join the crowd of technology gurus gathered here. I have a fair share of Microsoft exams behind me, a couple of acronyms after my name - MCSE, MCSD, and MCT, decent familiarity with majority of MS BackOffice products (SMS, SQL, Exchange, IIS), programming and scripting languages (VB, C++, VBScript with wsh) and several years of practical experience with Windows environment administration and engineering. My focus these days is on SQL Server and Windows 2000, and I'll attempt to share the most interesting experiences with these products.

Get the Free Newsletter!

Subscribe to Cloud Insider for top news, trends & analysis

Latest Articles