Hyperscale service tier

Applies to: Azure SQL Database

Azure SQL Database Hyperscale is a cost-efficient, high-performance cloud database.

Azure SQL Database is based on the SQL Database Engine. Hyperscale differs from other Azure SQL Database service tiers:

• Unlike other service tiers, Hyperscale has no SQL software license fee, which gives it a significant price advantage over other Azure SQL Database service tiers for high-performance databases.
• Hyperscale architecture is distinct: it provides nearly instantaneous backups, fast restores, and high throughput for reads and writes.
• Hyperscale provides fast compute scaling on demand without data movement.
• Read scale-out strategies are easy, with up to 30 named replicas with independent configurable compute, plus built-in high-availability replicas and configurable geo-replicas around the globe.

The Hyperscale service tier is suitable for all workload types. Compute and storage resources in Hyperscale substantially exceed the resources available in the Azure SQL Database General Purpose and Business Critical tiers.

You can convert an existing database in Azure SQL Database to Hyperscale easily, or migrate from any SQL Server database to Hyperscale. To migrate other databases to Azure SQL Database, see Azure Database Migration Guides.

The Hyperscale service tier is currently only available for Azure SQL Database, and not for Azure SQL Managed Instance.

What are the Hyperscale capabilities

The Hyperscale service tier in Azure SQL Database provides the following additional capabilities:

• Rapid scale up - scale up your compute resources to accommodate heavy workloads when needed, and then scale the compute resources back down when not needed.
• Rapid scale out - provision one or more read-only replicas for offloading your read workload and for use as hot-standbys.
• Automatic scale-up, scale-down, and billing for compute based on usage with serverless compute.
• Optimized price/performance for a group of Hyperscale databases with varying resource demands with elastic pools.
• Autoscaling storage with support for up to 128 TB of database or 100 TB elastic pool size.
• Higher overall performance due to higher transaction log throughput and faster transaction commit times regardless of data volumes.
• Fast database backups (based on file snapshots) regardless of size with no I/O impact on compute resources.
• Fast database restores or copies (based on file snapshots) in minutes rather than hours or days.

The Hyperscale service tier removes many of the practical limits traditionally seen in cloud databases. Where most other databases are limited by the resources available in a single node, databases in the Hyperscale service tier have no such limits. With its flexible storage architecture, storage grows as needed. In fact, Hyperscale databases aren't created with a defined max size. A Hyperscale database grows as needed - and you're billed only for the storage capacity allocated. For read-intensive workloads, the Hyperscale service tier provides rapid scale-out by provisioning additional replicas as needed for offloading read workloads.

Additionally, the time required to create database backups or to scale up or down is no longer tied to the volume of data in the database. Hyperscale databases are backed up virtually instantaneously. You can also scale a database in the tens of terabytes up or down within minutes in the provisioned compute tier or use serverless to scale compute automatically. This capability frees you from concerns about being boxed in by your initial configuration choices.

For more information about the compute sizes for the Hyperscale service tier, see Service tier characteristics.

For details on the General Purpose and Business Critical service tiers in the vCore-based purchasing model, see General Purpose and Business Critical service tiers. For a comparison of the vCore-based purchasing model with the DTU-based purchasing model, see Compare vCore and DTU-based purchasing models of Azure SQL Database.

Who should consider the Hyperscale service tier

The Hyperscale service tier is intended for all customers who require higher performance and availability, fast backup and restore, and fast storage and compute scalability. Hyperscale is ideal for customers who are moving to the cloud to modernize their applications, or for customers who are already using other service tiers in Azure SQL Database. The Hyperscale service tier supports a broad range of database workloads, from pure OLTP to pure analytics. It's optimized for OLTP and hybrid transaction and analytical processing (HTAP) workloads.

Hyperscale pricing model

For high performance databases, Hyperscale offers a significant price advantage over other Azure SQL Database service tiers. For more information, see Blog: Azure SQL Database Hyperscale pricing announcement from Ignite 2023. For pricing change details, see Blog: Azure SQL Database Hyperscale - lower, simplified pricing!

The Hyperscale service tier is available only in the vCore model and comes in two compute tiers. Billing for Hyperscale is based on the provisioned or serverless compute tier:

• Provisioned compute tier:

  The vCore compute cost reflects the total compute capacity that's continuously provisioned for the application. The Hyperscale compute unit price is per replica.

• Serverless compute tier:

  Serverless compute billing is based on usage. For more information, see Serverless compute tier for Azure SQL Database.

You don't specify the max data size when configuring a Hyperscale database. In the Hyperscale tier, you pay for storage based on actual allocation. Storage is automatically allocated between 10 GB and 128 TB, and grows as needed. For more information, see In what increments does my database size grow?.

Scale and performance advantages

Hyperscale separates the main database engine from the components that provide long-term storage and durability for the data. This architecture allows you to scale compute resources rapidly, without data movement, and to scale storage (up to 128 TB) independently of compute. For more details, including an architecture diagram, see Hyperscale architecture.

• With the ability to rapidly spin up/down additional read-only compute nodes, the Hyperscale architecture allows significant read scale capabilities and can also free up the primary compute node to serve more requests.
• You can provision the compute for secondary nodes, or use serverless compute. In either case, you can scale them up or down quickly because of the shared-storage architecture of Hyperscale.
  • Secondary high-availability compute node replicas in Hyperscale follow the compute tier of the primary, which results in low-impact failovers.
• When you use serverless, primary or secondary compute nodes automatically scale based on your workload demand.

The primary Azure SQL Database Hyperscale database handles both read and write workloads, but you can easily create read-only replicas as part of your application strategy:

• You can adjust the total number of high-availability secondary replicas from 0 to 4, depending on availability and scalability requirements.
• You can create up to 30 named replicas to support read scale-out workloads.
• You can achieve geo-distributed read scale-out across Azure global data centers by using geo-replicas.

Database high availability in Hyperscale

As in all other service tiers, Hyperscale guarantees data durability for committed transactions regardless of compute replica availability. The extent of downtime due to the primary replica becoming unavailable depends on the type of failover (planned vs. unplanned), whether zone redundancy is configured, and on the presence of at least one high-availability replica. In a planned failover (such as a maintenance event), the system either creates the new primary replica before initiating a failover or uses an existing high-availability replica as the failover target. In an unplanned failover (such as a hardware failure on the primary replica), the system uses a high-availability replica as a failover target if one exists, or creates a new primary replica from the pool of available compute capacity. In the latter case, downtime duration is longer due to extra steps required to create the new primary replica.

You can choose a maintenance window to make impactful maintenance events predictable and less disruptive for your workload.

For Hyperscale SLA, see SLA for Azure SQL Database.

Buffer pool and resilient buffer pool extension

In Azure Database Hyperscale, there is a distinct separation between compute and storage. Storage contains all the database pages in one database, and can be allocated over multiple machines as the database grows. The compute node, however, only caches what is being used recently. The hottest pages in compute are maintained in memory in a structure called buffer pool (BP). It is also stored in the local SSD, the resilient buffer pool extension (RBPEX), so data can be retrieved faster in case the compute process restarts.

In a cloud system, compute can move to different machines as needed. The compute layer can have multiple replicas. One replica is primary and receives all updates, while the others are secondary replicas. If the primary fails, the system promotes one of the high availability secondary replicas to primary in a process called failover. The secondary replica might not have a cache in its BP and RBPEX that's optimized for the primary workload.

Continuous priming

Continuous priming is a process that collects information about which pages are the most frequently accessed (hottest) in all compute replicas. The process aggregates this information, and high availability secondary replicas use the list of hottest pages that correspond to the typical customer workload. This process continuously fills both the BP and RBPEX with the hottest pages to keep up with changes in the customer workload.

Without continuous priming, both BP and RBPEX are not inherited by new high availability replicas, and only be reconstructed during the user workload. Continuous priming saves time and prevents inconsistent performance, as there is no wait before the caches are fully hydrated again. With continuous priming, new high availability secondary replicas will immediately start priming their BP and RBPEX. This will help maintain performance more consistently as failovers happen.

Continuous priming works both ways: high availability secondary replicas will cache pages being used in the primary replica, and the primary will cache pages with the workload from the secondary replicas.

Continuous priming is currently available on the Hyperscale provisioned compute tier.

Back up and restore

Back up and restore operations for Hyperscale databases are file-snapshot based. This approach makes these operations nearly instantaneous. Because the Hyperscale architecture uses the storage layer for backup and restore, it reduces the processing burden and performance impact on compute replicas. For more information, see Hyperscale backups and storage redundancy.

Disaster recovery for Hyperscale databases

To restore a Hyperscale database in Azure SQL Database to a region other than the one it's currently hosted in, perform a geo-restore. This method works for disaster recovery operations, drills, relocation, or any other reason. Geo-restore is only available when you choose geo-redundant storage (RA-GRS) for storage redundancy.

For more information, see restoring a Hyperscale database to a different region.

Compare resource limits

The vCore-based service tiers differ in database availability, storage type, performance, and maximum storage size. The following table describes these differences:

¹ Simplified pricing for SQL Database Hyperscale arrived in December 2023. Review the Hyperscale pricing blog for details.

² As of December 2023, Azure Hybrid Benefit isn't available for new Hyperscale databases, or in dev/test subscriptions. Existing Hyperscale single databases with provisioned compute can continue to use Azure Hybrid Benefit to save on compute costs until December 2026. For more information, review the Hyperscale pricing blog.

³ Currently, the 160 and 192 vCore options are a preview feature.

Compute resources

The following table compares compute resources in different hardware configurations and compute tiers for Azure SQL Database Hyperscale. For non-Hyperscale Azure SQL Database, see vCore purchasing model - Azure SQL Database.

* For a given compute size and hardware configuration, resource limits are the same regardless of CPU type (Intel® Broadwell, Skylake, Ice Lake, Cascade Lake, Emerald Rapid, or AMD Milan, Genoa). In the sys.dm_user_db_resource_governance dynamic management view, hardware generation for databases using:

• Intel® SP-8160 (Skylake) processors appears as Gen6
• Intel® 8272CL (Cascade Lake) appears as Gen7
• Intel® Xeon® Platinum 8370C (Ice Lake) or AMD EPYC™ 7763v (Milan) appear as Gen8
• AMD EPYC™ 9004 (Genoa) appear as Gen9 or Intel® Xeon® Platinum 8573C (Emerald Rapids) appear as Gen10

For more information, see resource limits for single databases and elastic pools.

Create and manage Hyperscale databases

You can create and manage Hyperscale databases by using the Azure portal, Transact-SQL, PowerShell, and the Azure CLI. For more information, see Quickstart: Create a Hyperscale database.

Limitations

These limitations currently apply to the Hyperscale service tier. The product team is actively working to remove as many of these limitations as possible.

Related content

• Frequently asked questions about Hyperscale
• Compare vCore and DTU-based purchasing models of Azure SQL Database
• Resource management in Azure SQL Database
• Resource limits for single databases using the vCore purchasing model
• Features comparison: Azure SQL Database and Azure SQL Managed Instance
• Hyperscale distributed functions architecture
• How to manage a Hyperscale database