Azure SQL Database Hyperscale Serverless Auto-Pause Preview: Costs, Limits and Setup

On Azure Updates, the item is listed as "In preview." Microsoft defines that status as available to all Azure customers for non-production use and testing. Don't treat this as production-ready yet.

What Microsoft announced​

The announcement came during SQLCon/FabCon Europe 2026 in Barcelona. In her roundup on the Azure SQL Dev Corner blog, Anna Hoffman, Principal Group Product Manager, lists the feature among several Hyperscale updates. She says it helps customers cut costs for development, test and other active workloads. Two other Hyperscale items shipped alongside it:

• 160 and 192 vCore Premium-series service objectives are now generally available.
• Expanded capacity for Hyperscale elastic pools is in preview, raising the limit to 50 databases and 128 TB per pool.

Microsoft Learn has already been updated. The serverless overview now says serverless auto-pause and auto-resume are a preview feature of Azure SQL Database Hyperscale. It also restates the basic idea: the serverless compute tier also automatically pauses databases during inactive periods when only storage is billed and automatically resumes databases when activity returns.

Summary: Hyperscale serverless itself isn't new. What's new is that it can pause and resume on its own, and that part is still preview only.

Why it matters​

Microsoft said early on that this was coming. When serverless for Hyperscale first went into preview in February 2023, Microsoft's Tech Community blog said serverless auto-pausing and resuming in Hyperscale is planned in a future release. InfoQ reported at the time that the company had scheduled the feature for a later Hyperscale release.

It took more than three years. Until now, admins had to accept a fixed minimum cost. As Windows News put it in July 2026, an idle Hyperscale database continues to consume at least the minimum vCore allocation, which means the compute meter never drops to zero even overnight or on weekends. A Microsoft Q&A answer from August 2025 said the same thing: while the compute vs storage billing is decoupled, your compute doesn't auto-pause today.

The billing works like this. Microsoft Learn says a serverless database's cost is compute plus storage. When the database is paused, compute cost drops to zero and you pay only for storage. For a dev database that sits idle from Friday night to Monday morning, those paused hours can add up. Microsoft hasn't published figures for how much Hyperscale customers will save during the preview, and we won't guess.

Hyperscale preview settings are not the same as General Purpose​

The updated Microsoft Learn pages list several ways the Hyperscale preview differs from General Purpose:

According to Microsoft Learn, the preview has two limitations:

1. Named replicas aren't supported with auto-pause and auto-resume in the current Hyperscale preview.
2. General Purpose databases with a short delay lose auto-pause when upgraded. If a General Purpose serverless database uses a delay under 60 minutes and you upgrade it to Hyperscale serverless, auto-pause is disabled after the upgrade. You have to turn it back on yourself. If your migration runbook assumes settings carry over, a database that used to pause after 15 minutes will quietly stay on and keep billing until someone notices.

Summary: Hyperscale lets you choose delays from one hour to seven days, it doesn't support named replicas with this feature, and upgrades from General Purpose need a check afterward.

How auto-pause and auto-resume behave​

Microsoft Learn's auto-pause article applies to both tiers and now includes the Hyperscale preview notes. Here's how it works.

What makes a database pause​

Auto-pause starts only when both of these hold for the whole delay period:

• There are zero sessions.
• CPU is zero for user workload in the user resource pool.

Some features stop a database from pausing at all. If you use any of them, you need to disable auto-pause:

• Active geo-replication and failover groups
• Long-term backup retention (LTR)
• A DNS alias on the logical server
• Acting as the sync database in SQL Data Sync (hub and member databases can still pause)
• Acting as the job database for elastic jobs (databases that elastic jobs target can still pause, but job connections wake them up)

Some service updates also block pausing until the update finishes.

What wakes a database up​

A login attempt is the obvious trigger. Microsoft Learn lists plenty of less obvious ones: viewing auditing records, looking at sensitivity labels or data masking rules, checking TDE status, vulnerability assessment scans, Query Store changes, performance recommendations, auto-tuning, database copies, BACPAC exports, and even adding Azure tags or changing the vCore range. Monitoring tools that poll a database can keep waking it up and cancel out the savings.

If you use customer-managed TDE keys, key rotation also resumes the database.

Latency and the error 40613 you'll see​

Resuming isn't instant. Microsoft Learn says when a serverless database is paused, the first connection attempt resumes the database. Applications might receive an error stating that the database is unavailable with error code 40613. Once the database is resumed, retry the connection. Microsoft generally puts auto-resume at about a minute and auto-pause at 1 to 10 minutes after the conditions are met. That guidance is written for serverless in general. Microsoft hasn't published separate timings for Hyperscale.

A practical checklist before you try it​

If you want to test this on a non-production Hyperscale serverless database, here's a sensible order:

1. Choose a suitable database. Dev, test or staging databases with long idle stretches fit best, and that matches Microsoft's own pitch. It's a preview, so leave production alone.
2. Check for blocking features. Geo-replication, failover groups, LTR, DNS aliases and named replicas will stop the feature from working.
3. Set a delay of at least 60 minutes. The Hyperscale preview won't go lower.
4. Make sure your apps retry connections. Microsoft says retry logic for serverless databases is especially important because temporary connectivity errors due to auto-resume are predictable. Clients that already follow Microsoft's retry guidance shouldn't need changes.
5. Find out what's keeping it awake. If the database never pauses, open sessions are the most common reason. Microsoft Learn gives a T-SQL query that joins sys.dm_exec_sessions with sys.dm_resource_governor_workload_groups to list them. Disconnect afterwards, because your own query session also stops the database from pausing.
6. Watch the activity log. In Azure Monitor, Resume Databases operations show what triggered each resume in the Caller property of the Started and Succeeded events.

For step-by-step setup in the portal, PowerShell, Azure CLI and T-SQL, Microsoft points to its "Create and configure a serverless database" page. We haven't found preview-specific setup instructions beyond that.

Some docs haven't caught up​

Microsoft's documentation isn't fully updated yet. The main overview and the auto-pause article now mention the Hyperscale preview. The serverless FAQ still says Hyperscale doesn't currently support auto-pause and auto-resume. The Azure China (21Vianet) copy of the overview also still says currently, auto-pause and auto-resume are only supported in the General Purpose service tier. These are most likely pages nobody has refreshed since the September 29 announcement. The preview does exist. But the Azure China docs haven't changed, so sovereign-cloud customers shouldn't assume the preview is available in their region.

Microsoft also hasn't said much about regions, preview pricing or a general availability date. Until it does, read the pages dated September 29 or later.

Our take​

This is a small feature, but it removes one of the main reasons to avoid Hyperscale for dev and test databases. Until now you had to choose between Hyperscale's architecture and a General Purpose database that could go idle and stop costing compute. Now you can get both.

There are downsides. The 60-minute minimum delay makes short idle gaps less useful. Named replicas aren't supported. And the upgrade issue that turns off auto-pause is easy to miss. Test it in a sandbox, add retry logic to your apps, and check what your monitoring tools are doing before counting on the savings.