What’s New in Azure SQL Database Serverless

Posted by Vivek Shankar

Recently there have been substantial improvements within the Azure SQL Database. This blog describes one such important improvement, Azure SQL Database Serverless. Currently, in preview mode, this computing level changes how we are billed (per second).

What is Serverless Computing Level?

Azure SQL Database Serverless is the computing level for discrete databases that automatically scale calculations based on workload needs and bills per second. The serverless computing level can automatically suspend databases when they are inactive, as storage is paid only during that time and resumes them when they become active.

The figure below shows the usage and billing pattern with serverless computing during active, inactive and paused periods.

Image source:

Performance Tuning

The minimum and maximum virtual cores (vCores) are configurable parameters. They define the range of computing resources that are available to the database. Memory and I/O limits are directly proportional to the definite range of vCores.

The auto-pause delay is a configurable parameter to determine the period for which the database needs to be inactive before it is paused. The database automatically resumes on the next action or log in. You also have the option to disable the suspension.

Best-Suited Scenarios for Serverless Computing

  • Individual databases with irregular, unpredictable patterns scattered with idle periods and lower average compute utilization over time.
  • Individual databases in the provisioned computing level that are frequently rescaled and customers preferring delegation of computation rescaling to the service.
  • New individual databases with no usage history and difficulty in estimation of the computation size before deployment in SQL Database.

Figure 2 demonstrates the use of minimum and maximum vCores and auto-pause delay.

The concept of being billed per second (based on the vCores used) rather than per hour means that pricing can be more granular, especially with the auto-pause option. Since auto-pause delay defines the period of time the database must be inactive before it is automatically paused (only charged for storage), we should only use it when we can afford some delay in computing warm-up after idle usage periods, otherwise, it is best to stick with provisioned computing level.

Autopausing and Autoresuming

Autopausing is triggered when the following conditions are true for the duration of the auto-pause delay:

  • Zero sessions
  • CPU usage is zero for user workload running in the user pool

Auto-pause is temporarily put on hold when there’s a deployment of some service updates, as they require the database to remain online till deployment is complete. Auto-pause is reactivated once the service update is completed.

Autoresuming is triggered if any of the following conditions are true at any time.

Feature Autoresume trigger
Authentication and authorization Login
Threat detection Enabling/ disabling threat detection settings at the server or database level. Modifying the threat detection settings at the server or database level.
Data discovery and classification Viewing, adding, modifying, or deleting sensitivity labels.
Auditing Viewing auditing records and updating or viewing auditing policy.
Data masking Viewing, adding, modifying, or deleting data masking rules.
Transparent data encryption View the state or status of transparent data encryption.
Query (performance) data store Viewing or modifying query store settings.
Autotuning Application and verification of autotuning recommendations like auto-indexing
Database copying Create a copy of the database and export it to a BACPAC file.
SQL data sync Synchronization between the hub and member databases that function on a configurable schedule or are performed manually
Modifying database metadata Adding new database tags and changing max & min vCores or auto-pause delay.
SQL Server Management Studio (SSMS) Leveraging SSMS versions prior to 18.1 to open a new query window for a database on the server that resumes any auto-paused database in the same server. The behavior does not occur when using SSMS versions later than 18.1.

Autoresuming is triggered during the deployment of certain service updates that require the database to be online.


In case a serverless database is paused, the first login will resume the database and return an error stating that the database is unavailable with error code 40613. After the database is resumed, the login is retried to establish connectivity. That said, database clients with connection retry logic are not modified.


The latency to auto-resume a serverless database is generally 1 minute and to auto-pause is 1-10 minutes.

Serverless Compute Vs Provisioned Compute

Below table summarizes distinctions between Serverless and Provisioned computing levels.

  Serverless Compute Provisioned Compute
Database usage pattern Irregular, unpredictable usage with lower average compute utilization over time. Regular usage patterns with higher average compute utilization over time, or multiple databases using elastic pools.
Performance management effort Lower Higher
Compute scaling Automatic Manual
Compute responsiveness Lower after inactive periods Irregular
Billing granularity Per second Per hour

Closing Lines

Microsoft Azure Serverless computing level is available worldwide except the following regions: Central Australia, East & North China, South France, Central Germany, Northeast Germany, West India, South Korea, West South Africa, West Central US, and North, South, & West UK.

Will share more on Serverless computing as and when there are updates from Microsoft. Till then enjoy the world of cloud computing.

That is it from our side. Let us know your thoughts in the comments below.

Until next time!

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *