The first request after a quiet night can fail before the database finishes waking up. Azure SQL Database serverless makes that behavior part of the application design, alongside its compute savings.
Separate Serverless Scaling from Pausing
Serverless adjusts compute within configured limits and bills compute usage while the database is online. Auto-pause is a separate capability for eligible General Purpose databases. Hyperscale supports this compute model, but currently does not support auto-pause and auto-resume.
The practical choice starts with workload behavior. An intermittently used reporting database has different availability expectations from an order-entry database. List the acceptable connection delay before selecting a cheaper-looking configuration.
I treat a pause policy as an application requirement, because the connection experience changes. I also review the background workload before trusting an idle period. A database can appear quiet to users while another process keeps visiting.
Scaling does not remove ordinary database design work. Inefficient queries, excessive round trips, and unsuitable indexes still consume resources. Set realistic limits after reviewing representative requests rather than assuming automatic scaling fixes every bottleneck.
Choose Serverless Minimum and Maximum Compute Together
Minimum vCores establish the lower compute boundary while the database remains online. Maximum vCores establish its upper boundary and influence associated resource limits. Memory configuration also affects the minimum compute charge.
A low minimum is attractive for intermittent demand, but examine memory and warm-up behavior. A low maximum can constrain a burst that arrives after an idle period. Evaluate those settings against the response time your application actually requires.
Use an approved test database for configuration experiments. Compare connection behavior, request latency, and billing metrics over the same representative schedule. Record the configured limits beside the measurements so the comparison remains reproducible.
Do not quote a universal monthly saving from a vCore setting alone. Region, resource configuration, workload, and online duration affect the result. Storage and applicable backup charges remain relevant even when compute pauses.
Configure the Delay in the Azure Portal
The following are Azure portal steps, described rather than executed here. Open the SQL database resource and select its compute configuration page. Confirm the General Purpose service tier and select the serverless compute tier.
Set minimum and maximum vCores, then review the auto-pause option. Choose a delay that reflects real gaps between requests and save the configuration. Reopen the page afterward to confirm the persisted settings.
The delay measures eligible inactivity before automatic pausing begins. It is not a schedule saying the database shuts down at a particular hour. Brief activity during the interval can prevent the required uninterrupted inactivity.
The supported delay currently starts at fifteen minutes and extends to seven days. Disabling automatic pausing keeps the database available while allowing compute scaling. Check the portal's available controls for the selected resource before planning a deployment change.
Find What Prevents a Pause
Auto-pause eligibility requires no sessions and no user workload CPU throughout the delay. An idle connection can therefore matter even without an active query. Inspect applications, monitoring, scheduled work, and open administrative windows.
Run the following query inside the target database using an appropriately authorized account. It lists visible user sessions other than the diagnostic connection. Limited session visibility means this result is not a complete investigation by itself.
SELECT session_id, login_name, host_name, program_name,
status, login_time, last_request_start_time,
last_request_end_time
FROM sys.dm_exec_sessions
WHERE is_user_process = 1
AND session_id <> @@SPID
ORDER BY login_time;Disconnect the diagnostic session when the inspection finishes. Repeatedly querying an idle database undermines the pause test you are trying to perform. The observer can become the workload, which is a surprisingly productive way to waste an afternoon.
Some features prevent pausing independently of ordinary application traffic. Active geo-replication, failover groups, long-term backup retention, and logical-server DNS aliases are examples. Review feature compatibility before promising a nightly pause.
A database used as an elastic job database also has restrictions on auto-pause. A target database can instead resume when a job connects. Preserve required resilience and retention features when comparing configurations; evaluate another compute choice when necessary.
Design for the First Connection after Idle
A connection attempt can trigger resume and return database-unavailable error 40613 before the database becomes ready. The application must retry connections for appropriate transient failures. Measure the complete request experience, including this startup phase.
Use bounded retries with a delay, a maximum elapsed budget, and useful application logging. Avoid launching many immediate retries from every request simultaneously. Coordinate the retry policy with connection pooling and the user's response-time budget.
Retrying a connection differs from blindly repeating a business transaction. An uncertain transaction outcome needs its own idempotency or reconciliation design. Do not turn every database exception into an unlimited request replay.
Connections are not the only resume triggers. Certain management changes, database copying, export operations, scheduled activity, and service updates can require an online database. Review the Azure activity log when an unexpected wake-up needs an explanation.
Read Usage without Mistaking CPU for the Bill
The following query reports recent resource samples from sys.dm_db_resource_stats. That view exists in Azure SQL Database, not in a local SQL Server instance. Run it while the database is already online and disconnect afterward. These percentages describe resource utilization, rather than a complete monetary bill.
SELECT TOP (40)
end_time,
avg_cpu_percent,
avg_data_io_percent,
avg_log_write_percent,
avg_memory_usage_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC;For billing-relevant compute usage, inspect the app_cpu_billed metric in Azure Monitor. Its unit is vCore seconds, so aggregate it appropriately over the comparison period. Keep the resource, time range, and aggregation consistent when comparing configurations.
Compute billing considers CPU and normalized memory, subject to their configured minimums. Memory is converted using three gigabytes per vCore for this calculation. A nearly flat CPU chart therefore does not establish a nearly zero compute charge.
An online database still has a minimum compute bill. When it is paused, compute billing stops, while storage-related costs remain. Use actual usage metrics and the applicable regional rate when estimating a budget.
Validate Serverless Availability and Savings Together
Portal status distinguishes online, pausing, paused, and resuming states. Use the activity log to inspect transitions without repeatedly opening database connections. This separates service-state monitoring from queries that alter the experiment.
Can the first user after an idle period wait through resume and a bounded connection retry? Test that experience with the actual application's timeout settings. A successful administrator connection does not prove the application handles the same condition.
Compare a realistic day with frequent gaps against a day with steady traffic. Include scheduled jobs, health checks, and administrative access in both schedules. The configuration earns its place when availability expectations and measured usage agree.
Related reading on this blog: Azure SQL Elastic Pools: Sharing Resources Across Many Databases and Azure SQL Hyperscale: When the Database Outgrows One Server.
Serverless is not an availability shortcut, it is a compute policy that must match application timing and workload behavior.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
