General Purpose service tier - Azure SQL Database and Azure SQL Managed Instance
Applies to:
Azure SQL Database
Azure SQL Managed Instance
Azure SQL Database and Azure SQL Managed Instance are based on the SQL Server database engine architecture adapted for the cloud environment in order to ensure default availability even in the cases of infrastructure failures.
This article describes and compares the General Purpose service tier used by Azure SQL Database and Azure SQL Managed instance. The General Purpose service tier is best used for budget-oriented, balanced compute and storage options.
Overview
The architectural model for the General Purpose service tier is based on a separation of compute and storage. This architectural model relies on high availability and reliability of Azure Blob storage that transparently replicates database files and guarantees no data loss if underlying infrastructure failure happens.
The following figure shows four nodes in standard architectural model with the separated compute and storage layers.
In the architectural model for the General Purpose service tier, there are two layers:
- A stateless compute layer that is running the
sqlservr.exe
process and contains only transient and cached data (for example – plan cache, buffer pool, column store pool). This stateless node is operated by Azure Service Fabric that initializes process, controls health of the node, and performs failover to another place if necessary. - A stateful data layer with database files (.mdf/.ldf) that are stored in Azure Blob storage. Azure Blob storage guarantees that there will be no data loss of any record that is placed in any database file. Azure Storage has built-in data availability/redundancy that ensures that every record in log file or page in data file will be preserved even if the process crashes.
Whenever the database engine or operating system is upgraded, some part of underlying infrastructure fails, or if some critical issue is detected in the sqlservr.exe
process, Azure Service Fabric will move the stateless process to another stateless compute node. There is a set of spare nodes that is waiting to run new compute service if a failover of the primary node happens in order to minimize failover time. Data in Azure storage layer is not affected, and data/log files are attached to newly initialized process. This process guarantees 99.99% availability by default and 99.995% availability when zone redundancy is enabled. There may be some performance impacts on heavy workloads that are running due to transition time and the fact the new node starts with cold cache.
When to choose this service tier
The General Purpose service tier is a default service tier in Azure SQL Database and Azure SQL Managed Instance that is designed for most of generic workloads. If you need a fully managed database engine with a default SLA and storage latency between 5 and 10 ms, the General Purpose tier is the option for you.
Compare General Purpose resource limits
Review the table in this section for a brief overview comparison of the resource limits for Azure SQL Database and Azure SQL managed Instance in the General Purpose service tier.
For comprehensive details about resource limits, review:
- Azure SQL Database: vCore single database, vCore pooled database , Hyperscale, DTU single database and DTU pooled databases
- Azure SQL Managed Instance: vCore instance limits
To compare features between SQL Database and SQL Managed Instance, see the database engine features.
The following table shows resource limits for both Azure SQL Database and Azure SQL Managed Instance in the General Purpose service tier:
Category | Azure SQL Database | Azure SQL Managed Instance |
---|---|---|
Compute size | 1 - 128 vCores | 4, 8, 16, 24, 32, 40, 64, 80 vCores |
Storage type | Remote storage | Remote storage |
Storage size | 1 GB - 4 TB | 2 GB - 16 TB |
Tempdb size | 32 GB per vCore | 24 GB per vCore |
Log write throughput | Single databases: 4.5 MB/s per vCore (max 50 MB/s) Elastic pools: 6 MB/s per vCore (max 62.5 MB/s) |
General Purpose: 3 MB/s per vCore (max 120 MB/s) Business Critical: 4 MB/s per vCore (max 96 MB/s) |
Availability | Default SLA 99.995% SLA with zone redundancy |
Default SLA |
Backups | 1-35 days (7 days by default) | 1-35 days (7 days by default) |
Read-only replicas | 0 built-in 0 - 4 geo-replicas |
0 built-in 0 - 1 geo-replicas using auto-failover groups |
Pricing/Billing | vCore, reserved storage, backup storage, and geo-replicas are charged. IOPS is not charged. |
vCore, reserved storage, backup storage, and geo-replicas are charged. IOPS is not charged. |
Discount models | Reserved instances Azure Hybrid Benefit (not available on dev/test subscriptions) Enterprise and Pay-As-You-Go Dev/Test subscriptions |
Reserved instances Azure Hybrid Benefit (not available on dev/test subscriptions) Enterprise and Pay-As-You-Go Dev/Test subscriptions |
Next steps
- Find resource characteristics (number of cores, I/O, memory) of the General Purpose/standard tier in SQL Managed Instance, single database in vCore model or DTU model, or elastic pool in vCore model and DTU model.
- Learn about Business Critical and Hyperscale service tiers.
- Learn about Service Fabric.
- For more options for high availability and disaster recovery, see Business Continuity.
Feedback
Submit and view feedback for