Overview Azure SQL Database resource limits

This article provides an overview of the Azure SQL Database resource limits and provides information regarding what happens when those resource limits are hit or exceeded.

What is the maximum number of servers and databases?

Maximum Logical server Managed instance
Databases per server/instance 5000 100
Default number of servers per subscription in any region 20 N/A
Max number of servers per subscription in any region 200 N/A
DTU / eDTU quota per server 54,000 N/A
vCore quota per server/instance 540 80
Max pools per server Limited by number of DTUs or vCores N/A


To obtain more DTU /eDTU quota, vCore quota, or more servers than the default amount, a new support request can be submitted in the Azure portal for the subscription with issue type “Quota”. The DTU / eDTU quota and database limit per server constrains the number of elastic pools per server.


As the number of databases approaches the limit per server, the following can occur:

  • Increasing latency in running queries against the master database. This includes views of resource utilization statistics such as sys.resource_stats.
  • Increasing latency in management operations and rendering portal viewpoints that involve enumerating databases in the server.

What happens when database resource limits are reached?

Compute (DTUs and eDTUs / vCores)

When database compute utilization (measured by DTUs and eDTUs, or vCores) becomes high, query latency increases and can even time out. Under these conditions, queries may be queued by the service and are provided resources for execution as resource become free. When encountering high compute utilization, mitigation options include:


When database space used reaches the max size limit, database inserts and updates that increase the data size fail and clients receive an error message. Database SELECTS and DELETES continue to succeed.

When encountering high space utilization, mitigation options include:

Sessions and workers (requests)

The maximum number of sessions and workers are determined by the service tier and compute size (DTUs and eDTUs). New requests are rejected when session or worker limits are reached, and clients receive an error message. While the number of connections available can be controlled by the application, the number of concurrent workers is often harder to estimate and control. This is especially true during peak load periods when database resource limits are reached and workers pile up due to longer running queries.

When encountering high session or worker utilization, mitigation options include:

Next steps