Azure SQL Database serverless auto-pause limits and feature support

Direct Answers

• Unsupported advanced features on serverless vCore: Advanced Threat Protection (Microsoft Defender for SQL) is not available on the General Purpose serverless tier; it requires Business Critical serverless or provisioned compute. In-Memory OLTP is unavailable on General Purpose serverless (supported only on Business Critical serverless). All other listed security features—Transparent Data Encryption, Always Encrypted, Row-Level Security, Dynamic Data Masking, Auditing—and performance features—Accelerated Database Recovery, Automatic Tuning, Query Store—are supported on both serverless tiers.
• Minimum auto-pause delay: 1 hour (60 minutes), configurable up to 1 week (10,080 minutes). This delay is independent of the minimum compute (min vCore) setting; min vCore controls the lowest vCore allocation while the database is active, not when it pauses.
• Conditions that block auto-pause: Any active session, open transaction, running query, or connection holding a lock prevents pausing. Idle connections retained in a connection pool count as active sessions and will block auto-pause until they are closed or returned to the pool.

Confirmed Feature Support Matrix

Feature	General Purpose Serverless	Business Critical Serverless
Transparent Data Encryption	Supported	Supported
Always Encrypted	Supported	Supported
Row-Level Security	Supported	Supported
Dynamic Data Masking	Supported	Supported
Auditing	Supported	Supported
Advanced Threat Protection (Microsoft Defender for SQL)	Not supported	Supported
In-Memory OLTP	Not supported	Supported
Accelerated Database Recovery	Supported	Supported
Automatic Tuning	Supported	Supported
Query Store	Supported	Supported

Auto-Pause Configuration Details

The auto-pause delay is set in minutes (60–10,080). The minVCore parameter defines the floor for compute scaling while the database is online; it does not influence the idle timer. A database with minVCore=0.5 and autoPauseDelay=60 will still wait 60 minutes of zero active sessions before pausing. When paused, billing is for storage only; resume latency on first connection is typically seconds to under a minute.

Why Connections Block Pausing

Azure SQL treats any authenticated session as "active" regardless of whether it is executing a query. Common scenarios that prevent pause:

• Application connection pools that keep connections open (e.g., default pool sizes in .NET, Java HikariCP, Node.js mssql)
• Long-running transactions or explicit BEGIN TRAN without commit/rollback
• Background jobs, change tracking, or CDC capture processes holding locks
• Query Editor sessions left open in the Azure portal

To allow auto-pause, ensure pools are configured with MinPoolSize=0 (or equivalent) and that applications explicitly close connections during idle periods.

Verification Steps

1. In the Azure portal: navigate to the database → Configure → Serverless to view/edit autoPauseDelay, minVCore, and maxVCore.
2. Via Azure CLI:

   az sql db show --resource-group <rg> --server <server> --name <db> \
     --query "{autoPauseDelay:autoPauseDelay, minVCore:minCapacity, maxVCore:maxCapacity, status:status}"

3. Test pause behavior: connect with sqlcmd, run a query, disconnect completely, then monitor az sql db show or the portal. After the configured delay with zero sessions, status should change to Paused.

One Diagnostic Detail Needed

If auto-pause is not triggering as expected, provide the output of sys.dm_exec_sessions (or sp_who2) during the presumed idle window. This will confirm whether pooled or orphaned sessions are keeping the database active.