Skip to content

Latest commit

 

History

History
100 lines (76 loc) · 11.7 KB

service-tiers-general-purpose-business-critical.md

File metadata and controls

100 lines (76 loc) · 11.7 KB
title titleSuffix description services ms.service ms.subservice ms.custom ms.devlang ms.topic author ms.author ms.reviewer ms.date
General purpose and business critical service tiers
Azure SQL Database & SQL Managed Instance
The article discusses the general purpose and business critical service tiers in the vCore-based purchasing model used by Azure SQL Database and Azure SQL Managed Instance.
sql-database
sql-db-mi
features
sqldbrb=2
conceptual
stevestein
sstein
sashan, moslake, carlrab
01/30/2020

Azure SQL Database and Azure SQL Managed Instance service tiers

[!INCLUDEappliesto-sqldb-sqlmi]

Azure SQL Database and Azure SQL Managed Instance are based on SQL Server database engine architecture that's adjusted for the cloud environment to ensure 99.99 percent availability, even if there is an infrastructure failure. Two service tiers are used by Azure SQL Database and Azure SQL Managed Instance, each with a different architectural model. These service tiers are:

  • General purpose, which is designed for budget-oriented workloads.
  • Business critical, which is designed for low-latency workloads with high resiliency to failures and fast failovers.

Azure SQL Database has an additional service tier:

  • Hyperscale, which is designed for most business workloads, providing highly scalable storage, read scale-out, and fast database restore capabilities.

This article discusses differences between the service tiers, storage and backup considerations for the general purpose and business critical service tiers in the vCore-based purchasing model.

Service tier comparison

The following table describes the key differences between service tiers for the latest generation (Gen5). Note that service tier characteristics might be different in SQL Database and SQL Managed Instance.

Resource type General Purpose Hyperscale Business Critical
Best for Offers budget oriented balanced compute and storage options. Most business workloads. Auto-scaling storage size up to 100 TB, fluid vertical and horizontal compute scaling, fast database restore. OLTP applications with high transaction rate and low IO latency. Offers highest resilience to failures and fast failovers using multiple synchronously updated replicas.
Available in resource type: SQL Database / SQL Managed Instance Single Azure SQL Database SQL Database / SQL Managed Instance
Compute size SQL Database 1 to 80 vCores 1 to 80 vCores 1 to 80 vCores
SQL Managed Instance 4, 8, 16, 24, 32, 40, 64, 80 vCores N/A 4, 8, 16, 24, 32, 40, 64, 80 vCores
SQL Managed Instance pools 2, 4, 8, 16, 24, 32, 40, 64, 80 vCores N/A N/A
Storage type All Premium remote storage (per instance) De-coupled storage with local SSD cache (per instance) Super-fast local SSD storage (per instance)
Database size SQL Database 5 GB – 4 TB Up to 100 TB 5 GB – 4 TB
SQL Managed Instance 32 GB – 8 TB N/A 32 GB – 4 TB
Storage size SQL Database 5 GB – 4 TB Up to 100 TB 5 GB – 4 TB
SQL Managed Instance 32 GB – 8 TB N/A 32 GB – 4 TB
TempDB size SQL Database 32 GB per vCore 32 GB per vCore 32 GB per vCore
SQL Managed Instance 24 GB per vCore N/A Up to 4 TB - limited by storage size
Log write throughput SQL Database 1.875 MB/s per vCore (max 30 MB/s) 100 MB/s 6 MB/s per vCore (max 96 MB/s)
SQL Managed Instance 3 MB/s per vCore (max 22 MB/s) N/A 4 MB/s per vcore (max 48 MB/s)
Availability All 99.99% 99.95% with one secondary replica, 99.99% with more replicas 99.99%
99.995% with zone redundant single database
Backups All RA-GRS, 7-35 days (7 days by default) RA-GRS, 7 days, constant time point-in-time recovery (PITR) RA-GRS, 7-35 days (7 days by default)
In-memory OLTP N/A N/A Available
Read-only replicas 0 built-in
0 - 4 using geo-replication		 0 - 4 built-in 1 built-in, included in price
0 - 4 using geo-replication
Pricing/billing SQL Database vCore, reserved storage, and backup storage are charged.
IOPS is not charged.		 vCore for each replica and used storage are charged.
IOPS not yet charged.		 vCore, reserved storage, and backup storage are charged.
IOPS is not charged.
SQL Managed Instance vCore, reserved storage, and backup storage is charged.
IOPS is not charged		 N/A vCore, reserved storage, and backup storage is 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		 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

For more information, see the detailed differences between the service tiers in Azure SQL Database (vCore), single Azure SQL Database (DTU), pooled Azure SQL Database (DTU), and Azure SQL Managed Instance pages.

Note

For information about the hyperscale service tier in the vCore-based purchasing model, see hyperscale service tier. For a comparison of the vCore-based purchasing model with the DTU-based purchasing model, see purchasing models and resources.

Data and log storage

The following factors affect the amount of storage used for data and log files, and apply to General Purpose and Business Critical. For details on data and log storage in Hyperscale, see Hyperscale service tier.

  • The allocated storage is used by data files (MDF) and log files (LDF).
  • Each single database compute size supports a maximum database size, with a default maximum size of 32 GB.
  • When you configure the required single database size (the size of the MDF file), 30 percent more additional storage is automatically added to support LDF files.
  • You can select any single database size between 10 GB and the supported maximum.
    • For storage in the standard or general purpose service tiers, increase or decrease the size in 10-GB increments.
    • For storage in the premium or business critical service tiers, increase or decrease the size in 250-GB increments.
  • In the general purpose service tier, tempdb uses an attached SSD, and this storage cost is included in the vCore price.
  • In the business critical service tier, tempdb shares the attached SSD with the MDF and LDF files, and the tempdb storage cost is included in the vCore price.
  • The storage size for a SQL Managed Instance must be specified in multiples of 32 GB.

Important

You are charged for the total storage allocated for MDF and LDF files.

To monitor the current total size of your MDF and LDF files, use sp_spaceused. To monitor the current size of the individual MDF and LDF files, use sys.database_files.

Important

Under some circumstances, you may need to shrink a database to reclaim unused space. For more information, see Manage file space in Azure SQL Database.

Backups and storage

Storage for database backups is allocated to support the point-in-time restore (PITR) and long-term retention (LTR) capabilities of SQL Database and SQL Managed Instance. This storage is allocated separately for each database and billed as two separate per-database charges.

  • PITR: Individual database backups are copied to read-access geo-redundant (RA-GRS) storage automatically. The storage size increases dynamically as new backups are created. The storage is used by weekly full backups, daily differential backups, and transaction log backups, which are copied every 5 minutes. The storage consumption depends on the rate of change of the database and the retention period for backups. You can configure a separate retention period for each database between 7 and 35 days. A minimum storage amount equal to 100 percent (1x) of the database size is provided at no extra charge. For most databases, this amount is enough to store 7 days of backups.
  • LTR: You also have the option to configure long-term retention of full backups for up to 10 years (this feature is in limited public preview for SQL Managed Instance. If you set up an LTR policy, these backups are stored in RA-GRS storage automatically, but you can control how often the backups are copied. To meet different compliance requirements, you can select different retention periods for weekly, monthly, and/or yearly backups. The configuration you choose determines how much storage will be used for LTR backups. To estimate the cost of LTR storage, you can use the LTR pricing calculator. For more information, see SQL Database long-term retention.

Next steps

For details about the specific compute and storage sizes available in the general purpose and business critical service tiers, see: