Azure SQL Database Serverless vs Provisioned: Choose Compute for Variable Workloads

The decision

You have an Azure SQL Database with usage that is bursty or idle for long periods. The decision is serverless compute with auto-pause and per-second billing versus provisioned compute with continuous billing and steady-state performance. The constraints that force the choice are pause latency tolerance, need for Elastic Pools, and feature requirements.

Constraints to check first

• Latency sensitivity on first request after idle. Serverless resumes from pause with cold-start latency.
• Multi-database resource sharing. Serverless cannot be placed in an Elastic Pool.
• Feature set. Some advanced compute features are not available on serverless.
• Cost model. Serverless bills compute per second used plus storage per GB; provisioned bills compute continuously.

Options compared

Trade-offs

Cost vs readiness

Serverless reduces cost for workloads with significant idle time because compute stops. The minimum auto-pause delay is configurable, with a maximum pause duration limit. Provisioned maintains ready-state performance with no pause latency, at the cost of paying for idle compute.

Scaling behavior

Serverless auto-scales vCores up and down within the user-defined min and max. Provisioned requires explicit scale operations or external automation such as Azure Automation to change vCores.

Architecture limits

Serverless cannot be used inside an Elastic Pool. Architectures that rely on pool-level resource sharing for many databases must use provisioned compute or redesign. Most core SQL features are supported on serverless, but features that require a dedicated compute instance such as in-memory OLTP, extended stored procedures, or distributed transactions are not available.

Concrete validation plan

The following shows how to create a serverless database and observe pause and scale behavior. Run commands from a local terminal with Azure CLI installed. Required permission is Contributor on the target resource group.

az sql db create \
  --resource-group <resource-group> \
  --server <server-name> \
  --name <database-name> \
  --edition GeneralPurpose \
  --family Gen5 \
  --capacity 2 \
  --compute-model Serverless \
  --min-vcores 0.5 \
  --max-vcores 4 \
  --auto-pause-delay 60

Meaningful placeholders: <resource-group>, <server-name>, <database-name>. Expected checks after creation: the database shows compute model Serverless, min vCore 0.5, max vCore 4, auto-pause delay 60 minutes in the Azure portal Overview.

Risk: changing compute model requires a database recreation in some scenarios. Auto-pause can cause first query latency after idle. Do not set min vCore to zero for production workloads that need baseline performance.

Monitor pause and scale

• In Azure Monitor Metrics, add metrics compute_cpu_percent and pause_status for the database. Observe pause_status transitions and CPU scaling within the min/max range.
• In Azure Cost Management, compare monthly cost of the serverless database against a provisioned database in the same service tier with equivalent vCores. Verify cost tracks actual usage.
• Run a controlled test workload that alternates idle and active periods. Measure query latency before and after idle to confirm cold-start delay and that auto-scale adjusts vCores within the defined range.

Limitations and verification

Serverless is not supported in Elastic Pools. Cold-start latency can affect latency-sensitive or real-time applications. Auto-pause delay has a minimum value and maximum pause duration. Verify feature support for your workload before committing, as some advanced compute features are not available on serverless.

Practical way to check result: confirm pause_status metric shows paused after the configured idle period and resumes on first connection, and that vCore usage stays between min and max during load. Document the observed resume latency for your acceptance criteria.