Azure SQL Database Limits and Throttling

Service Tiers and Resource Limits

Azure SQL Database offers various service tiers, each with specific limits on compute, storage, and I/O. Understanding these limits is crucial for capacity planning and avoiding performance bottlenecks.

General Purpose Service Tier Limits

Resource	vCore (4 vCores)	vCore (8 vCores)	vCore (16 vCores)
Max Data Size	1 TB	2 TB	4 TB
Max IOPS	3200	6400	12800
Max Throughput (MBps)	250	500	1000
Max CPU Percentage	95%	95%	95%
Max Memory Percentage	85%	85%	85%

Business Critical Service Tier Limits

Resource	vCore (4 vCores)	vCore (8 vCores)
Max Data Size	1 TB	2 TB
Max IOPS	20000	40000
Max Throughput (MBps)	400	800
Max CPU Percentage	95%	95%
Max Memory Percentage	85%	85%

Hyperscale Service Tier Limits

Hyperscale offers significantly higher limits and a different architecture. Key limits include:

Max Data Size: Up to 100 TB.
Log Rate: Up to 100 MB/sec.
Max Concurrent Workers: Scales dynamically.

Note: Specific limits can vary based on the Azure region and the exact configuration of your Azure SQL Database. Always refer to the official Azure documentation for the most up-to-date information.

Throttling Mechanisms

Azure SQL Database employs several throttling mechanisms to ensure fair resource sharing and prevent a single database from impacting others. These include:

CPU Throttling

If your database's CPU utilization consistently exceeds the allocated limit for its service tier, Azure SQL Database will throttle CPU resources. This can manifest as increased query execution times.

IOPS and Throughput Throttling

Similar to CPU, exceeding the maximum IOPS or throughput limits will result in throttling. This impacts disk-intensive operations like reads and writes.

Log Rate Throttling

For write-heavy workloads, the rate at which transaction log records can be written is also limited, especially critical in the Hyperscale tier.

Worker Thread Throttling

There are limits on the number of concurrent worker threads that can be active within a database. Exceeding this can lead to query queuing.

Connection Throttling

While less common for typical applications, there are limits on the number of concurrent connections to a database, particularly at lower service tiers.

Monitoring and Best Practices

To effectively manage limits and throttling, regular monitoring is essential.

Key Metrics to Monitor

CPU Percentage
Data IOPercentage
Log Write Throughput
Worker Percentage
DDL Execution Rate

Best Practices

Choose the Right Service Tier: Select a tier that aligns with your application's expected workload.
Optimize Queries: Well-written queries reduce resource consumption.
Index Effectively: Proper indexing improves read performance and reduces IOPS.
Monitor Performance: Use Azure Monitor and SQL Database tools to track resource usage.
Scale Up/Out: If consistently hitting limits, consider scaling your database to a higher tier or using features like Elastic Pools for multiple databases.
Handle Throttling Gracefully: Implement retry logic with exponential backoff in your applications.

Example: Checking CPU Usage

You can use the following T-SQL query to check current CPU utilization:


SELECT
    (current_cpu_usage_percent) AS cpu_usage
FROM sys.dm_db_resource_stats
WHERE database_name = 'YourDatabaseName';