SQL Database options and performance: Understand what's available in each service tier

10 min to read Contributors

Azure SQL Database offers three service tiers, Basic, Standard, and Premium, with multiple performance levels to handle different workloads. Higher performance levels provide increasings resources designed to deliver increasingly higher throughput. You can change service tiers and performance levels dynamically without downtime. Basic, Standard, and Premium service tiers all have an uptime SLA of 99.99%, flexible business continuity options, security features, and hourly billing.

You can create single databases with dedicated resource on the performance level selected. You can also manage multiple databases in an elastic pool in which the resources are shared across the databases. The resources available for single databases are expressed in terms of Database Transaction Units (DTUs) and for elastic pools in terms of elastic DTUs (eDTUs). For more on DTUs and eDTUs, see What is a DTU?

In both cases, the service tiers include Basic, Standard, and Premium.

Choosing a service tier

The following table provides examples of the tiers best suited for different application workloads.

Service tier Target workloads
Basic Best suited for a small database, supporting typically one single active operation at a given time. Examples include databases used for development or testing, or small-scale infrequently used applications.
Standard The go-to option for cloud applications with low to medium IO performance requirements, supporting multiple concurrent queries. Examples include workgroup or web applications.
Premium Designed for high transactional volume with high IO performance requirements, supporting many concurrent users. Examples are databases supporting mission critical applications.

First decide if you want to run a single database or if you want to group databases that shares resources. Review the elastic pool considerations. To decide on a service tier, start by determining the minimum database features that you need:

  • Max database size for individual databases (2 GB maximum for Basic, 250 GB maximum for Standard, and 500 GB to 1 TB maximum for Premium in the high end performance levels)
  • Maximum total storage in an elastic pool (117 GB for Basic, 1200 GB for Standard, and 750 GB for Premium)
  • Maximum number of databases per pool (400 for Basic, 400 for Standard, and 50 for Premium)
  • Database backup retention period (7 days for Basic, 35 days for Standard and Premium)

Once you have determined the minimum service tier, you are ready to determine the performance level for the database (the number of DTUs). The standard S2 and S3 performance levels are often a good starting point. For databases with high CPU or IO requirements, the Premium performance levels are the right starting point. Premium offers more CPU and starts at 10x more IO compared to the highest Standard performance level.

Single database service tiers and performance levels

For single databases, there are multiple performance levels within each service tier. You have the flexibility to choose the level that best meets your workload’s demands. If you need to scale up or down, you can easily change the tiers of your database. See Changing Database Service Tiers and Performance Levels for details.

Regardless of the number of databases hosted, your database gets a guaranteed set of resources and the expected performance characteristics of your database are not affected.

Basic service tier

Service tier Basic
Max DTUs 5
Max database size* 2 GB
Max in-memory OLTP storage N/A
Max concurrent workers 30
Max concurrent logins 30
Max concurrent sessions 300

Standard service tier

Service tier S0 S1 S2 S3
Max DTUs 10 20 50 100
Max database size* 250 GB 250 GB 250 GB 250 GB
Max in-memory OLTP storage N/A N/A N/A N/A
Max concurrent workers 60 90 120 200
Max concurrent logins 60 90 120 200
Max concurrent sessions 600 900 1200 2400

Premium service tier

Service tier P1 P2 P4 P6 P11 P15
Max DTUs 125 250 500 1000 1750 4000
Max database size* 500 GB 500 GB 500 GB 500 GB 1 TB 1 TB
Max in-memory OLTP storage 1 GB 2 GB 4 GB 8 GB 14 GB 32 GB
Max concurrent workers 200 400 800 1600 2400 6400
Max concurrent logins 200 400 800 1600 2400 6400
Max concurrent sessions 30000 30000 30000 30000 30000 30000

* Max database size refers to the maximum size of the data files and does not include the space used by log files.

Note

For a detailed explanation of all other rows in this service tiers table, see Service tier capabilities and limits.

Scaling up or scaling down a single database

After initially picking a service tier and performance level, you can scale a single database up or down dynamically based on actual experience.

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. This window varies, but is on average under 4 seconds, and in more than 99% of cases is less than 30 seconds. If there are large numbers of transactions in flight at the moment connections are disabled, this window 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 6 hours. For a database of the same size that is changing performance levels within the Premium service tier, it should complete within 3 hours.

  • To downgrade a database, the database should be smaller than the maximum allowed size of the target service tier.
  • When upgrading a database with Geo-Replication enabled, you must first upgrade its secondary databases to the desired performance tier before upgrading the primary database.
  • When downgrading from a Premium service tier, you must first terminate all Geo-Replication relationships. You can follow the steps described in the Recover from an outage topic to stop the replication process between the primary and the active secondary databases.
  • The restore service offerings are different for the various service tiers. If you are downgrading you may lose the ability to restore to a point in time, or have a lower backup retention period. For more information, see Azure SQL Database Backup and Restore.
  • The new properties for the database are not applied until the changes are complete.
Important

For detailed steps, see Managing single databases with the Azure portal, Managing single databases with Powershell, or Managing single databases with Transact-SQL.

Elastic pool service tiers and performance in eDTUs

Pools allow databases to share and consume eDTU resources without needing to assign a specific performance level to each database in the pool. For example, a single database in a Standard pool can go from using 0 eDTUs to the maximum database eDTU you set up when you configure the pool. Pools allow multiple databases with varying workloads to efficiently use eDTU resources available to the entire pool. See Price and performance considerations for an elastic pool for details.

The following table describes the characteristics of pool service tiers.

Basic elastic pool limits

Pool size (eDTUs) 50 100 200 300 400 800 1200 1600
Max storage per pool* 5 GB 10 GB 20 GB 29 GB 39 GB 78 GB 117 GB 156 GB
Max In-Memory OLTP storage per pool* 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 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 per database {0, 5} {0, 5} {0, 5} {0, 5} {0, 5} {0, 5} {0, 5} {0, 5}
Max eDTUs per database {5} {5} {5} {5} {5} {5} {5} {5}

Standard elastic pool limits

Pool size (eDTUs) 50 100 200 300 400 800
Max storage per pool* 50 GB 100 GB 200 GB 300 GB 400 GB 800 GB
Max In-Memory OLTP storage per pool* 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 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 per database {0,10,20,
50}		 {0,10,20,
50,100}		 {0,10,20,
50,100}		 {0,10,20,
50,100}		 {0,10,20,
50,100}		 {0,10,20,
50,100}
Max eDTUs per database {10,20,
50}		 {10,20,
50,100}		 {10,20,
50,100}		 {10,20,
50,100}		 {10,20,
50,100}		 {10,20,
50,100}

Standard elastic pool limits (continued)

Pool size (eDTUs) 1200 1600 2000 2500 3000
Max storage per pool* 1.2 TB 1.6 TB 2 TB 2.4 TB 2.9 TB
Max In-Memory OLTP storage per pool* N/A N/A N/A N/A N/A
Max number DBs per pool 500 500 500 500 500
Max concurrent workers 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 per database {0,10,20,
50,100}		 {0,10,20,
50,100}		 {0,10,20,
50,100}		 {0,10,20,
50,100}		 {0,10,20,
50,100}
Max eDTUs per database {10,20,
50,100}		 {10,20,
50,100}		 {10,20,
50,100}		 {10,20,
50,100}		 {10,20,
50,100}

Premium elastic pool limits

Pool size (eDTUs) 125 250 500 1000 1500
Max storage per pool* 250 GB 500 GB 750 GB 750 GB 750 GB
Max In-Memory OLTP storage per pool* 1 GB 2 GB 4 GB 10 GB 12 GB
Max number DBs per pool 50 100 100 100 100
Max concurrent workers per pool 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}

Premium elastic pool limits (continued)

Pool size (eDTUs) 2000 2500 3000 3500 4000
Max storage per pool* 750 GB 750 GB 750 GB 750 GB 750 GB
Max In-Memory OLTP storage per pool* 16 GB 20 GB 24 GB 28 GB 32 GB
Max number DBs per pool 100 100 100 100 100
Max concurrent workers 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 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 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}

* Pooled databases share pool storage, so database storage is limited to the smaller of the remaining pool storage or max storage per database. Max storage per pool refers to the maximum storage of the data files in the pool and does not include space used by log files.

Each database within a pool also adheres to the single database characteristics for that tier. For example, the Basic pool has a limit for max sessions per pool of 4800 - 28800, but an individual database within a Basic pool has a database limit of 300 sessions.

Scaling up or scaling down an elastic pool

After initially picking a service tier and performance level, you can scale the elastic pool up or down dynamically based on actual experience.

  • Changing the min eDTUs per database or max eDTUs per database typically completes in five minutes or less.
  • Time to change the pool size (eDTUs) depends on the combined size of all databases in the pool. Changes average 90 minutes or less per 100 GB. For example, if the total space of all databases in the pool is 200 GB, then the expected latency for changing the pool eDTU per pool is 3 hours or less.
Important

For detailed steps, see Managing elastic pools with the Azure portal, Managing elastic pools with Powershell, Managing elastic pools with Transact-SQL, or Managing elastic pools with C#.

Next steps