Azure SQL Database resource limits

Single database: Storage sizes and performance levels

For single databases, the following tables show the resources available for a single database at each service tier and performance level. You can set the service tier, performance level, and storage amount for a single database using the Azure portal, Transact-SQL, PowerShell, the Azure CLI, or the REST API.

Basic service tier

Performance level Basic
Max DTUs 5
Included storage (GB) 2
Max storage choices (GB) 2
Max in-memory OLTP storage (GB) N/A
Max concurrent workers (requests) 30
Max concurrent logins 30
Max concurrent sessions 300

Standard service tier

Performance level S0 S1 S2 S3
Max DTUs** 10 20 50 100
Included storage (GB) 250 250 250 250
Max storage choices (GB)* 250 250 250 250, 500, 750, 1024
Max in-memory OLTP storage (GB) N/A N/A N/A N/A
Max concurrent workers (requests) 60 90 120 200
Max concurrent logins 60 90 120 200
Max concurrent sessions 600 900 1200 2400

Standard service tier (continued)

Performance level S4 S6 S7 S9 S12
Max DTUs** 200 400 800 1600 3000
Included storage (GB) 250 250 250 250 250
Max storage choices (GB)* 250, 500, 750, 1024 250, 500, 750, 1024 250, 500, 750, 1024 250, 500, 750, 1024 250, 500, 750, 1024
Max in-memory OLTP storage (GB) N/A N/A N/A N/A N/A
Max concurrent workers (requests) 400 800 1600 3200 6000
Max concurrent logins 400 800 1600 3200 6000
Max concurrent sessions 4800 9600 19200 30000 30000

Premium service tier

Performance level P1 P2 P4 P6 P11 P15
Max DTUs 125 250 500 1000 1750 4000
Included storage (GB) 500 500 500 500 4096 4096
Max storage choices (GB)* 500, 750, 1024 500, 750, 1024 500, 750, 1024 500, 750, 1024 4096 4096
Max in-memory OLTP storage (GB) 1 2 4 8 14 32
Max concurrent workers (requests) 200 400 800 1600 2400 6400
Max concurrent logins 200 400 800 1600 2400 6400
Max concurrent sessions 30000 30000 30000 30000 30000 30000

Premium RS service tier

Performance level PRS1 PRS2 PRS4 PRS6
Max DTUs 125 250 500 1000
Included storage (GB) 500 500 500 500
Max storage choices (GB)* 500, 750, 1024 500, 750, 1024 500, 750, 1024 500, 750, 1024
Max in-memory OLTP storage (GB) 1 2 4 8
Max concurrent workers (requests) 200 400 800 1600
Max concurrent logins 200 400 800 1600
Max concurrent sessions 30000 30000 30000 30000

Important

* Storage sizes greater than the amount of included storage are in preview and extra costs apply. For details, see SQL Database pricing.

* In the Premium tier, more than 1 TB of storage is currently available in the following regions: US East2, West US, US Gov Virginia, West Europe, Germany Central, South East Asia, Japan East, Australia East, Canada Central, and Canada East. See P11-P15 Current Limitations.

** Max DTUs per database starting at 200 DTUs and higher in Standard are in preview.

Single database: change storage size

  • The DTU price for a single database includes a certain amount of storage at no additional cost. Extra storage beyond the included amount can be provisioned for an additional cost up to the max size limit in increments of 250 GB up to 1 TB, and then in increments of 256 GB beyond 1 TB. For included storage amounts and max size limits, see Single database: Storage sizes and performance levels.
  • Extra storage for a single database can be provisioned by increasing its max size using the Azure portal, Transact-SQL, PowerShell, the Azure CLI, or the REST API.
  • The price of extra storage for a single database is the extra storage amount multiplied by the extra storage unit price of the service tier. For details on the price of extra storage, see SQL Database pricing.

Single database: change DTUs

After initially picking a service tier, performance level, and storage amount, you can scale a single database up or down dynamically based on actual experience using the Azure portal, Transact-SQL, PowerShell, the Azure CLI, or the REST API.

The following video shows dynamically changing the performance tier to increase available DTUs for a single database.

Changing the service tier and/or performance level of a database creates a replica of the original database at the new performance level, and then switches connections over to the replica. No data is lost during this process but during the brief moment when we switch over to the replica, connections to the database are disabled, so some transactions in flight may be rolled back. The length of time for the switch-over varies, but is generally under 4 seconds is less than 30 seconds 99% of the time. If there are large numbers of transactions in flight at the moment connections are disabled, the length of time for the switch-over may be longer.

The duration of the entire scale-up process depends on both the size and service tier of the database before and after the change. For example, a 250-GB database that is changing to, from, or within a Standard service tier, should complete within six hours. For a database the same size that is changing performance levels within the Premium service tier, the scale-up should complete within three hours.

Tip

To check on the status of an ongoing SQL database scaling operation, you can use the following query: select * from sys.dm_operation_status.

  • If you are upgrading to a higher service tier or performance level, the database max size does not increase unless you explicitly specify a larger size (maxsize).
  • To downgrade a database, the database used space must be smaller than the maximum allowed size of the target service tier and performance level.
  • When downgrading from Premium or Premium RS to the Standard tier, an extra storage cost applies if both (1) the max size of the database is supported in the target performance level, and (2) the max size exceeds the included storage amount of the target performance level. For example, if a P1 database with a max size of 500 GB is downsized to S3, then an extra storage cost applies since S3 supports a max size of 500 GB and its included storage amount is only 250 GB. So, the extra storage amount is 500 GB – 250 GB = 250 GB. For pricing of extra storage, see SQL Database pricing. If the actual amount of space used is less than the included storage amount, then this extra cost can be avoided by reducing the database max size to the included amount.
  • When upgrading a database with geo-replication enabled, upgrade its secondary databases to the desired performance tier before upgrading the primary database (general guidance). When upgrading to a different, upgrading the secondary database first is required.
  • When downgrading a database with geo-replication enabled, downgrade its primary databases to the desired performance tier before downgrading the secondary database (general guidance). When downgrading to a different edition, downgrading the primary database first is required.
  • The restore service offerings are different for the various service tiers. If you are downgrading to the Basic tier, there is a lower backup retention period - see Azure SQL Database Backups.
  • The new properties for the database are not applied until the changes are complete.

Single database: limitations of P11 and P15 when the maximum size greater than 1 TB

A maximum size greater than 1 TB for P11 and P15 database is supported in the following regions: US East2, West US, US Gov Virginia, West Europe, Germany Central, South East Asia, Japan East, Australia East, Canada Central, and Canada East. The following considerations and limitations apply to P11 and P15 databases with a maximum size greater than 1 TB:

  • If you choose a maximum size greater than 1 TB when creating a database (using a value of 4 TB or 4096 GB), the create command fails with an error if the database is provisioned in an unsupported region.
  • For existing P11 and P15 databases located in one of the supported regions, you can increase the maximum storage to beyond 1 TB in increments of 256 GB up to 4 TB. To see if a larger size is supported in your region, use the DATABASEPROPERTYEX function or inspect the database size in the Azure portal. Upgrading an existing P11 or P15 database can only be performed by a server-level principal login or by members of the dbmanager database role.
  • If an upgrade operation is executed in a supported region the configuration is updated immediately. The database remains online during the upgrade process. However, you cannot utilize the full amount of storage beyond 1 TB of storage until the actual database files have been upgraded to the new maximum size. The length of time required depends upon on the size of the database being upgraded.
  • When creating or updating a P11 or P15 database, you can only choose between 1-TB and 4-TB maximum size in increments of 256 GB. When creating a P11/P15, the default storage option of 1 TB is pre-selected. For databases located in one of the supported regions, you can increase the storage maximum to up to a maximum of 4 TB for a new or existing single database. For all other regions, the maximum size cannot be increased above 1 TB. The price does not change when you select 4 TB of included storage.
  • If the maximum size of a database is set to greater than 1 TB, then it cannot be changed to 1 TB even if the actual storage used is below 1 TB. Thus, you cannot downgrade a P11 or P15 with a maximum size larger than 1 TB to a 1 TB P11 or 1 TB P15 or lower performance tier, such as P1-P6). This restriction also applies to the restore and copy scenarios including point-in-time, geo-restore, long-term-backup-retention, and database copy. Once a database is configured with a maximum size greater than 1 TB, all restore operations of this database must be run into a P11/P15 with a maximum size greater than 1 TB.
  • For active geo-replication scenarios:
    • Setting up a geo-replication relationship: If the primary database is P11 or P15, the secondary(ies) must also be P11 or P15; lower performance tiers are rejected as secondaries since they are not capable of supporting more than 1 TB.
    • Upgrading the primary database in a geo-replication relationship: Changing the maximum size to more than 1 TB on a primary database triggers the same change on the secondary database. Both upgrades must be successful for the change on the primary to take effect. Region limitations for the more than 1-TB option apply. If the secondary is in a region that does not support more than 1 TB, the primary is not upgraded.
  • Using the Import/Export service for loading P11/P15 databases with more than 1 TB is not supported. Use SqlPackage.exe to import and export data.

Elastic pool: storage sizes and performance levels

For SQL Database elastic pools, the following tables show the resources available at each service tier and performance level. You can set the service tier, performance level, and storage amount using the Azure portal, PowerShell, the Azure CLI, or the REST API.

Note

The resource limits of individual databases in elastic pools are generally the same as for single databases outside of pools based on DTUs and the service tier. For example, the max concurrent workers for an S2 database is 120 workers. So, the max concurrent workers for a database in a Standard pool is also 120 workers if the max DTU per database in the pool is 50 DTUs (which is equivalent to S2).

Basic elastic pool limits

eDTUs per pool 50 100 200 300 400 800 1200 1600
Included storage per pool (GB) 5 10 20 29 39 78 117 156
Max storage choices per pool (GB) 5 10 20 29 39 78 117 156
Max In-Memory OLTP storage per pool (GB) N/A N/A N/A N/A N/A N/A N/A N/A
Max number DBs per pool 100 200 500 500 500 500 500 500
Max concurrent workers (requests) per pool 100 200 400 600 800 1600 2400 3200
Max concurrent logins per pool 100 200 400 600 800 1600 2400 3200
Max concurrent sessions per pool 30000 30000 30000 30000 30000 30000 30000 30000
Min eDTUs choices per database 0, 5 0, 5 0, 5 0, 5 0, 5 0, 5 0, 5 0, 5
Max eDTUs choices per database 5 5 5 5 5 5 5 5
Max storage per database (GB) 2 2 2 2 2 2 2 2

Standard elastic pool limits

eDTUs per pool 50 100 200 300 400 800
Included storage per pool (GB) 50 100 200 300 400 800
Max storage choices per pool (GB)* 50, 250, 500 100, 250, 500, 750 200, 250, 500, 750, 1024 300, 500, 750, 1024, 1280 400, 500, 750, 1024, 1280, 1536 800, 1024, 1280, 1536, 1792, 2048
Max In-Memory OLTP storage per pool (GB) N/A N/A N/A N/A N/A N/A
Max number DBs per pool 100 200 500 500 500 500
Max concurrent workers (requests) per pool 100 200 400 600 800 1600
Max concurrent logins per pool 100 200 400 600 800 1600
Max concurrent sessions per pool 30000 30000 30000 30000 30000 30000
Min eDTUs choices per database** 0, 10, 20, 50 0, 10, 20, 50, 100 0, 10, 20, 50, 100, 200 0, 10, 20, 50, 100, 200, 300 0, 10, 20, 50, 100, 200, 300, 400 0, 10, 20, 50, 100, 200, 300, 400, 800
Max eDTUs choices per database** 10, 20, 50 10, 20, 50, 100 10, 20, 50, 100, 200 10, 20, 50, 100, 200, 300 10, 20, 50, 100, 200, 300, 400 10, 20, 50, 100, 200, 300, 400, 800
Max storage per database (GB)* 500 750 1024 1024 1024 1024

Standard elastic pool limits (continued)

eDTUs per pool 1200 1600 2000 2500 3000
Included storage per pool (GB) 1200 1600 2000 2500 3000
Max storage choices per pool (GB)* 1200, 1280, 1536, 1792, 2048, 2304, 2560 1600, 1792, 2048, 2304, 2560, 2816, 3072 2000, 2048, 2304, 2560, 2816, 3072, 3328, 3584 2500, 2560, 2816, 3072, 3328, 3584, 3840, 4096 3000, 3072, 3328, 3584, 3840, 4096
Max In-Memory OLTP storage per pool (GB) N/A N/A N/A N/A N/A
Max number DBs per pool 500 500 500 500 500
Max concurrent workers (requests) per pool 2400 3200 4000 5000 6000
Max concurrent logins per pool 2400 3200 4000 5000 6000
Max concurrent sessions per pool 30000 30000 30000 30000 30000
Min eDTUs choices per database** 0, 10, 20, 50, 100, 200, 300, 400, 800, 1200 0, 10, 20, 50, 100, 200, 300, 400, 800, 1200, 1600 0, 10, 20, 50, 100, 200, 300, 400, 800, 1200, 1600, 2000 0, 10, 20, 50, 100, 200, 300, 400, 800, 1200, 1600, 2000, 2500 0, 10, 20, 50, 100, 200, 300, 400, 800, 1200, 1600, 2000, 2500, 3000
Max eDTUs choices per database** 10, 20, 50, 100, 200, 300, 400, 800, 1200 10, 20, 50, 100, 200, 300, 400, 800, 1200, 1600 10, 20, 50, 100, 200, 300, 400, 800, 1200, 1600, 2000 10, 20, 50, 100, 200, 300, 400, 800, 1200, 1600, 2000, 2500 10, 20, 50, 100, 200, 300, 400, 800, 1200, 1600, 2000, 2500, 3000
Max storage choices per database (GB)* 1024 1024 1024 1024 1024

Premium elastic pool limits

eDTUs per pool 125 250 500 1000 1500
Included storage per pool (GB) 250 500 750 1024 1536
Max storage choices per pool (GB)* 250, 500, 750, 1024 500, 750, 1024 750, 1024 1024 1536
Max In-Memory OLTP storage per pool (GB) 1 2 4 10 12
Max number DBs per pool 50 100 100 100 100
Max concurrent workers per pool (requests) 200 400 800 1600 2400
Max concurrent logins per pool 200 400 800 1600 2400
Max concurrent sessions per pool 30000 30000 30000 30000 30000
Min eDTUs per database 0, 25, 50, 75, 125 0, 25, 50, 75, 125, 250 0, 25, 50, 75, 125, 250, 500 0, 25, 50, 75, 125, 250, 500, 1000 0, 25, 50, 75, 125, 250, 500, 1000, 1500
Max eDTUs per database 25, 50, 75, 125 25, 50, 75, 125, 250 25, 50, 75, 125, 250, 500 25, 50, 75, 125, 250, 500, 1000 25, 50, 75, 125, 250, 500, 1000, 1500
Max storage per database (GB)* 1024 1024 1024 1024 1024

Premium elastic pool limits (continued)

eDTUs per pool 2000 2500 3000 3500 4000
Included storage per pool (GB) 2048 2560 3072 3548 4096
Max storage choices per pool (GB)* 2048 2560 3072 3548 4096
Max In-Memory OLTP storage per pool (GB) 16 20 24 28 32
Max number DBs per pool 100 100 100 100 100
Max concurrent workers (requests) per pool 3200 4000 4800 5600 6400
Max concurrent logins per pool 3200 4000 4800 5600 6400
Max concurrent sessions per pool 30000 30000 30000 30000 30000
Min eDTUs choices per database 0, 25, 50, 75, 125, 250, 500, 1000, 1750 0, 25, 50, 75, 125, 250, 500, 1000, 1750 0, 25, 50, 75, 125, 250, 500, 1000, 1750 0, 25, 50, 75, 125, 250, 500, 1000, 1750 0, 25, 50, 75, 125, 250, 500, 1000, 1750, 4000
Max eDTUs choices per database 25, 50, 75, 125, 250, 500, 1000, 1750 25, 50, 75, 125, 250, 500, 1000, 1750 25, 50, 75, 125, 250, 500, 1000, 1750 25, 50, 75, 125, 250, 500, 1000, 1750 25, 50, 75, 125, 250, 500, 1000, 1750, 4000
Max storage per database (GB)* 1024 1024 1024 1024 1024

Premium RS elastic pool limits

eDTUs per pool 125 250 500 1000
Included storage per pool (GB) 250 500 750 750
Max storage choices per pool (GB)* 250, 500, 750, 1024 500, 750, 1024 750, 1024 1024
Max In-Memory OLTP storage per pool (GB) 1 2 4 10
Max number DBs per pool 50 100 100 100
Max concurrent workers (requests) per pool 200 400 800 1600
Max concurrent logins per pool 200 400 800 1600
Max concurrent sessions per pool 30000 30000 30000 30000
Min eDTUs choices per database 0, 25, 50, 75, 125 0, 25, 50, 75, 125, 250 0, 25, 50, 75, 125, 250, 500 0, 25, 50, 75, 125, 250, 500, 1000
Max eDTUs choices per database 25, 50, 75, 125 25, 50, 75, 125, 250 25, 50, 75, 125, 250, 500 25, 50, 75, 125, 250, 500, 1000
Max storage per database (GB)* 1024 1024 1024 1024

Important

* Storage sizes greater than the amount of included storage are in preview and extra costs apply. For details, see the SQL Database pricing page. Storage sizes greater than the amount of included storage are in preview and extra costs apply. For details, see the SQL Database pricing page.

* In the Premium tier, more than 1 TB of storage is currently available in the following regions: US East2, West US, US Gov Virginia, West Europe, Germany Central, South East Asia, Japan East, Australia East, Canada Central, and Canada East.

** Min/max eDTUs per database starting at 200 eDTUs and higher in Standard pools are in preview.

If all DTUs of an elastic pool are used, then each database in the pool receives an equal amount of resources to process queries. The SQL Database service provides resource sharing fairness between databases by ensuring equal slices of compute time. Elastic pool resource sharing fairness is in addition to any amount of resource otherwise guaranteed to each database when the DTU min per database is set to a non-zero value.

Database properties for pooled databases

The following table describes the properties for pooled databases.

Property Description
Max eDTUs per database The maximum number of eDTUs that any database in the pool may use, if available based on utilization by other databases in the pool. Max eDTU per database is not a resource guarantee for a database. This setting is a global setting that applies to all databases in the pool. Set max eDTUs per database high enough to handle peaks in database utilization. Some degree of overcommitting is expected since the pool generally assumes hot and cold usage patterns for databases where all databases are not simultaneously peaking. For example, suppose the peak utilization per database is 20 eDTUs and only 20% of the 100 databases in the pool are peak at the same time. If the eDTU max per database is set to 20 eDTUs, then it is reasonable to overcommit the pool by 5 times, and set the eDTUs per pool to 400.
Min eDTUs per database The minimum number of eDTUs that any database in the pool is guaranteed. This setting is a global setting that applies to all databases in the pool. The min eDTU per database may be set to 0, and is also the default value. This property is set to anywhere between 0 and the average eDTU utilization per database. The product of the number of databases in the pool and the min eDTUs per database cannot exceed the eDTUs per pool. For example, if a pool has 20 databases and the eDTU min per database set to 10 eDTUs, then the eDTUs per pool must be at least as large as 200 eDTUs.
Max storage per database The maximum storage for a database in a pool. Pooled databases share pool storage, so database storage is limited to the smaller of remaining pool storage and max storage per database. Max storage per database refers to the maximum size of the data files and does not include the space used by log files.

Elastic pool: change storage size

  • The eDTU price for an elastic pool includes a certain amount of storage at no additional cost. Extra storage beyond the included amount can be provisioned for an additional cost up to the max size limit in increments of 250 GB up to 1 TB, and then in increments of 256 GB beyond 1 TB. For included storage amounts and max size limits, see Elastic pool: storage sizes and performance levels.
  • Extra storage for an elastic pool can be provisioned by increasing its max size using the Azure portal, PowerShell, the Azure CLI, or the REST API.
  • The price of extra storage for an elastic pool is the extra storage amount multiplied by the extra storage unit price of the service tier. For details on the price of extra storage, see SQL Database pricing.

Elastic pool: change eDTUs

You can increase or decrease the resources available to an elastic pool based on resource needs using the Azure portal, PowerShell, the Azure CLI, or the REST API.

  • When rescaling pool eDTUs, database connections are briefly dropped. This is the same behavior as occurs when rescaling DTUs for a single database (not in a pool). For details on the duration and impact of dropped connections for a database during rescaling operations, see Rescaling DTUs for a single database.
  • The duration to rescale pool eDTUs can depend on the total amount of storage space used by all databases in the pool. In general, the rescaling latency averages 90 minutes or less per 100 GB. For example, if the total space used by all databases in the pool is 200 GB, then the expected latency for rescaling the pool is 3 hours or less. In some cases within the Standard or Basic tier, the rescaling latency can be under five minutes regardless of the amount of space used.
  • In general, the duration to change the min eDTUs per database or max eDTUs per database is five minutes or less.
  • When downsizing pool eDTUs, the pool used space must be smaller than the maximum allowed size of the target service tier and pool eDTUs.
  • When rescaling pool eDTUs, an extra storage cost applies if (1) the storage max size of the pool is supported by the target pool, and (2) the storage max size exceeds the included storage amount of the target pool. For example, if a 100 eDTU Standard pool with a max size of 100 GB is downsized to a 50 eDTU Standard pool, then an extra storage cost applies since target pool supports a max size of 100 GB and its included storage amount is only 50 GB. So, the extra storage amount is 100 GB – 50 GB = 50 GB. For pricing of extra storage, see SQL Database pricing. If the actual amount of space used is less than the included storage amount, then this extra cost can be avoided by reducing the database max size to the included amount.

What happens when database and elastic pool resource limits are reached?

Compute (DTUs and eDTUs)

When database compute utilization (measured by DTUs and eDTUs) 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:

Storage

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:

  • Increasing the max size of the database or elastic pool, or change the performance level to obtain more included storage. See SQL Database Resource Limits.
  • If the database is in an elastic pool, then alternatively the database can be moved outside of the pool so that its storage space is not shared with other databases.

Sessions and workers (requests)

The maximum number of concurrent sessions and workers are determined by the service tier and performance level (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