Develop and Scale Without Limits: Azure SQL Database Hyperscale Explained

---

Every traditional database has a ceiling. You provision storage, you provision compute, and when your workload grows beyond what you provisioned you go through a painful resize process that involves downtime, data movement, and carefully planned maintenance windows. For decades that constraint was simply the cost of running a relational database at scale.

Azure SQL Database Hyperscale was built to remove that ceiling. It is a cloud-native service tier that decouples compute from storage entirely, scales storage to 100TB without data movement, adds read replicas in minutes, and backs up databases of any size in near real time. The architecture underneath it is fundamentally different from any traditional SQL Server deployment, and understanding how it works changes how you think about database sizing, scaling, and design in the cloud.

This article covers what Hyperscale is, how the architecture works, what it costs, when it is the right choice, and what every DBA and developer needs to know before building on it.

1 The Problem Hyperscale Solves Beginner

Traditional SQL Server databases, whether on-premises or in Azure SQL Database General Purpose and Business Critical tiers, couple compute and storage together. The same server that runs your queries also owns your data files. When you need more storage you resize the database. When you need more compute you resize the instance. Both operations involve the database engine, both have size and time constraints, and neither is instantaneous.

The specific problems this creates at scale are predictable. Database backup time grows linearly with database size. A 10TB database takes much longer to back up than a 1TB database. Restore time follows the same pattern. Adding a read replica requires copying all the data to the new replica, which takes hours or days for large databases. Scaling compute up requires a service operation that takes minutes and in some cases requires a brief connection interruption.

Hyperscale separates these concerns completely. Storage is a distributed page-server system that is independent of compute. Compute nodes connect to shared storage rather than owning storage. This means adding compute does not move data, adding replicas does not copy data, and backup does not scan the entire database. Each operation becomes fast regardless of database size because it operates on metadata and snapshots rather than data files.

2 How the Architecture Works Beginner

Hyperscale uses a distributed architecture with four distinct layers. Understanding what each layer does makes every Hyperscale behavior predictable: why backups are fast, why replicas are fast, why compute scaling is fast, and why storage grows automatically.

3 The Four Components of Hyperscale Intermediate

Microsoft’s Hyperscale architecture documentation describes four components that work together to deliver the capabilities of the service. Each has a specific role and understanding them explains why the system behaves the way it does.

The practical consequence of this architecture is that all Hyperscale operations that seem impossible at scale become routine. Near-instantaneous backup works because it is a snapshot of Azure storage blobs, not a scan of data files. Fast replica creation works because a new compute node connects to existing page servers rather than receiving a data copy. Automatic storage growth works because new page servers are added to the distributed storage layer without touching the compute layer.

4 Storage: Up to 100TB, Scales Automatically Beginner

Hyperscale databases can grow to 100TB with no manual intervention. Storage is automatically allocated as the database grows and there is no need to pre-provision storage capacity. You do not choose a storage size when creating a Hyperscale database because the question is irrelevant. The database uses what it needs up to the 100TB limit.

Storage pricing for Hyperscale is separate from compute pricing. Storage costs $0.25 per GB per month. Unlike General Purpose and Business Critical tiers where compute and storage are priced together within tier limits, Hyperscale separates them. A 2 vCore Hyperscale database can hold up to 100TB of data with no storage-to-vCore constraint. This is one of the most significant architectural differences from other Azure SQL Database service tiers.

The absence of filegroup management is worth noting specifically for DBAs coming from on-premises SQL Server. In Hyperscale, data files are added to the PRIMARY filegroup automatically. The architectural reasons for creating additional filegroups in traditional SQL Server do not apply in Hyperscale. The distributed page-server storage layer handles data distribution automatically.

-- Check database size in Hyperscale
-- Standard T-SQL works the same as on-premises SQL Server
SELECT
    name,
    size * 8 / 1024                         AS SizeMB,
    size * 8 / 1024 / 1024                  AS SizeGB,
    max_size                                AS MaxSizePages,
    CASE max_size WHEN -1 THEN 'Unlimited' ELSE CAST(max_size * 8 / 1024 AS NVARCHAR(20)) END AS MaxSizeMB
FROM sys.database_files;

-- Hyperscale-specific: check resource governance settings
SELECT
    max_storage_percent,
    max_log_rate,
    primary_max_log_rate
FROM sys.dm_user_db_resource_governance;

5 Compute: Provisioned and Serverless Intermediate

Hyperscale offers two compute models. Understanding the difference determines which one fits your workload and budget.

Provisioned Compute

A fixed number of vCores are allocated and billed per hour regardless of utilization. Provisioned compute scales up or down in single-digit minutes with no data movement. This is faster than other Azure SQL Database tiers because Hyperscale compute scaling does not involve moving data between storage layers.

Provisioned compute ranges from 2 vCores to 128 vCores in standard configurations, with 160 and 192 vCore options in preview as of 2026. Prices start from $0.366 per hour.

Serverless Compute

Compute scales automatically within a defined minimum and maximum vCore range. Scaling operations take less than a second for serverless compute, regardless of database size. Serverless compute can also auto-pause during periods of inactivity, stopping compute billing entirely while the database waits for the next connection.

Serverless is billed per second of compute used rather than per hour of allocated compute. For workloads with unpredictable demand, variable usage patterns, or development and test environments where the database sits idle for extended periods, serverless significantly reduces cost.

Feature	Provisioned	Serverless
Billing model	Per hour of allocated vCores	Per second of vCores used
Scale speed	Single-digit minutes	Under one second
Auto-pause	Not available	Available (configurable delay)
Cold start after pause	N/A	Connection delay after auto-pause
Best for	Steady production workloads	Variable or dev/test workloads
Min vCores	2	0.5 (while active)

6 Read Replicas: Up to 30 Named Replicas Intermediate

Hyperscale supports three types of secondary replicas, each serving a different purpose. 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.

High Availability Replicas

Up to four HA replicas per primary or named replica. A High Availability replica uses the same page servers as the primary replica, so no data copy is required to add an HA replica. HA replicas provide standby capacity for failover and can serve read-only workloads. They are part of the Hyperscale service tier pricing and do not require separate compute billing.

Named Replicas

Each named replica is configurable with the same or different compute size than the primary, enabling independent scaling of read-write and read-only compute capacity. Hyperscale supports up to 30 named replicas, each with configurable compute. Named replicas share the same page servers as the primary which means they are added quickly without data movement. They are billed separately as additional compute resources.

Named replicas are particularly powerful for read scale-out scenarios where different workloads need different compute sizes. A reporting workload that runs complex analytical queries can have a named replica with 32 vCores while the primary runs OLTP workloads on 8 vCores. Both connect to the same underlying data without any synchronization overhead.

Geo-Replicas

With active geo-replication, you can create a readable secondary replica of the primary Hyperscale database in the same or in a different Azure region. When you create a geo-replica, all data is copied from the primary to a different set of page servers. A geo-replica does not share page servers with the primary, even if they are in the same region. This provides the necessary redundancy for geo-failover scenarios.

-- Create a named replica for read scale-out
-- Run this from the primary server context
-- The named replica connects to the same shared storage automatically

ALTER DATABASE [YourHyperscaleDB]
ADD SECONDARY ON SERVER [your-secondary-server]
WITH (SERVICE_OBJECTIVE = 'HS_Gen5_8',   -- independent compute size
      SECONDARY_TYPE = NAMED,
      DATABASE_NAME = 'YourHyperscaleDB_ReadReplica');

-- Connect read-heavy workloads to named replica using ApplicationIntent
-- No code changes needed in queries themselves
-- Change: Server=your-server;ApplicationIntent=ReadOnly;Database=YourHyperscaleDB_ReadReplica

-- Check replica lag on the primary
SELECT
    replica_server_name,
    synchronization_state_desc,
    secondary_lag_seconds
FROM sys.dm_geo_replication_link_status;

7 Backups and Restores Beginner

Backup behavior in Hyperscale is one of its most compelling operational advantages, particularly for organizations with large databases where traditional backup windows are a constant maintenance burden.

Hyperscale backups are snapshot-based. Instead of reading every page of a potentially multi-terabyte database and writing them to backup storage, the service takes a snapshot of the Azure storage blobs that hold the data files. This operation completes in near real time regardless of database size. A 100TB Hyperscale database backup completes in approximately the same time as a 100GB Hyperscale database backup.

Point-in-time restore works by combining the most recent snapshot with transaction log replay. Microsoft’s documentation states restore operations complete in minutes for most databases. The configurable retention period is 1 to 35 days.

-- Point-in-time restore in Hyperscale
-- Available via Azure Portal, Azure CLI, or PowerShell
-- T-SQL restore is not used directly for Azure SQL Database

-- Azure CLI example:
az sql db restore
  --dest-name YourHyperscaleDB-Restored
  --edition Hyperscale
  --resource-group YourResourceGroup
  --server YourServerName
  --name YourHyperscaleDB
  --time "2026-05-25T10:30:00Z"

-- Check backup retention setting
SELECT
    name,
    backup_retention_days
FROM sys.databases
WHERE name = DB_NAME();

-- Database copy in Hyperscale (near-instantaneous regardless of size)
-- Azure Portal: copy database
-- T-SQL equivalent:
CREATE DATABASE YourHyperscaleDB_Copy
AS COPY OF [source-server].YourHyperscaleDB;

8 High Availability and Geo-Replication Intermediate

Hyperscale’s high availability model uses the distributed architecture to provide resilience without the storage overhead of traditional HA approaches. Because compute nodes connect to shared page servers rather than owning storage, a failed compute node can be replaced by another compute node that connects to the same page servers. No storage failover is needed because storage is already distributed and independently durable.

The default HA configuration includes the primary compute replica and the distributed page server storage with built-in Azure storage redundancy. Adding HA secondary replicas improves read availability and failover speed. Up to four HA replicas can be added per primary.

For disaster recovery, geo-replicas can be placed in different Azure regions. Unlike named replicas which share page servers, geo-replicas maintain their own separate page server copies to ensure true geographic redundancy. Failover to a geo-replica promotes it to primary with its own independent storage layer.

9 Hyperscale vs General Purpose vs Business Critical Beginner

Feature	General Purpose	Business Critical	Hyperscale
Max storage	4 TB	4 TB	100 TB
Max vCores	128	128	128 (192 in preview)
Storage model	Coupled with compute	Local SSD (fast, expensive)	Decoupled, auto-scaling
Compute scaling speed	Minutes	Minutes	Single-digit minutes (provisioned), under 1 second (serverless)
Backup speed	Size-dependent	Size-dependent	Near-instantaneous (snapshot)
Read replicas	1 geo-replica	4 built-in HA replicas	Up to 30 named replicas plus HA and geo
Serverless compute	Available	Not available	Available
In-memory OLTP	Not available	Available	Available
Local SSD cache (RBPEX)	Not available	Local SSD storage	RBPEX on compute nodes
Best for	General workloads, standard HA	Mission-critical, ultra-low latency	Large databases, scale-out, variable workloads

10 When Hyperscale Is the Right Choice Beginner

Hyperscale is suited for all workload types including OLTP, hybrid transactional and analytical workloads, and data mart scenarios. If you are currently running interactive analytics queries using SQL Server as a data warehouse, Hyperscale is a great option because you can host small and mid-size data warehouses such as a few TB up to 128 TB at a lower cost, and you can migrate your SQL Server data warehouse workloads to Hyperscale with minimal T-SQL code changes.

The scenarios where Hyperscale delivers the most value over other tiers are:

• Databases approaching or exceeding the 4TB limit of General Purpose and Business Critical tiers. Hyperscale’s 100TB limit removes the ceiling entirely.
• Workloads requiring rapid read scale-out. Up to 30 named replicas with independent compute sizing makes Hyperscale the natural choice for multi-tenant applications or workloads with distinct read and write patterns that need separate scaling.
• Applications with unpredictable growth. Not having to plan storage capacity in advance eliminates a common cloud database management overhead.
• Development and test environments against large databases. Near-instantaneous database copy means spinning up a dev environment with production-scale data takes minutes rather than hours.
• Workloads needing fast restore. Organizations with strict RTO requirements benefit from Hyperscale’s snapshot-based restore that completes in minutes regardless of database size.
• AI and multi-agent workloads. Hyperscale’s core architecture enables several patterns that are particularly valuable for multi-agent systems. Named replicas can be dedicated exclusively to AI workloads, preventing agent query load from impacting primary OLTP performance.

11 Limitations and What to Watch Intermediate

Hyperscale is not a drop-in replacement for every workload. These are the limitations and considerations that matter most for planning.

Migration to Hyperscale Is One Way

Once a database is migrated to the Hyperscale service tier, it cannot be migrated back to General Purpose or Business Critical without exporting the data and recreating the database in the target tier. This is the most important constraint to understand before migrating a production database. Evaluate thoroughly before committing.

Cross-Database Queries and Transactions

Cross-database queries within the same logical server work in Hyperscale. However cross-database distributed transactions using the Microsoft Distributed Transaction Coordinator are not supported. Applications that rely on DTC-based distributed transactions need to be refactored before migrating to Hyperscale.

Log Rate Governance

Hyperscale applies log rate governance limits that cap the rate at which transactions can be written to the log service. Very high write throughput workloads may encounter log rate limits that do not exist in on-premises SQL Server. Test high-write workloads specifically before migration.

Named Replica Lag

Named replicas are read-only and lag slightly behind the primary. The lag is typically low but is not zero. Applications reading from named replicas must tolerate eventual consistency for recently committed data. This is standard read-replica behavior but worth confirming for applications that require read-after-write consistency on the same connection.

Feature Parity

Most SQL Server features work in Hyperscale. However some features available in General Purpose and Business Critical are not supported or have different behavior. Always verify specific feature requirements against the official Hyperscale documentation before migrating.

12 Pricing and Cost Management Intermediate

Hyperscale pricing has two independent components: compute and storage. They scale and are billed independently which is one of the architectural advantages.

Compute Pricing

Provisioned compute prices start from $0.366 per hour. Serverless compute is billed per second of vCores used rather than per hour of allocated compute. For variable workloads the serverless model can reduce cost significantly compared to provisioned compute at the equivalent peak size.

Storage Pricing

Storage costs $0.25 per GB per month. Since storage scales automatically you are billed for what you use. There is no need to pre-provision storage capacity and no penalty for databases that grow unexpectedly.

Named Replica Pricing

Each named replica is billed as additional compute at the vCore size you configure for it. A named replica running 4 vCores is billed at the 4 vCore provisioned compute rate. There is no separate storage charge for named replicas that share page servers with the primary.

Cost Management Tips

• Use serverless compute for development and test Hyperscale databases with auto-pause enabled. Billing stops during idle periods.
• Right-size named replicas independently. A read-heavy reporting replica can use more vCores than the primary OLTP database if that is where the compute demand is.
• Monitor actual storage consumption. The automatic growth is convenient but easy to overlook. Set Azure Monitor alerts on database size to avoid surprise storage costs.
• Azure Reserved Capacity provides discounts of up to 33% for 1 or 3 year commitments on provisioned compute.

13 Migration: Moving to Hyperscale Intermediate

Migrating an existing Azure SQL Database to Hyperscale is a service tier change that can be performed through the Azure Portal, Azure CLI, or PowerShell. It does not require exporting and reimporting data. The migration process is online and Microsoft states it completes in minutes for most database sizes.

-- Check current service tier before migration
SELECT
    DATABASEPROPERTYEX(DB_NAME(), 'ServiceObjective') AS CurrentServiceObjective,
    DATABASEPROPERTYEX(DB_NAME(), 'Edition')          AS CurrentEdition;

-- Change service tier to Hyperscale via Azure CLI
az sql db update
  --resource-group YourResourceGroup
  --server YourServerName
  --name YourDatabaseName
  --edition Hyperscale
  --service-objective HS_Gen5_4   -- 4 vCore provisioned Hyperscale

-- Change to Hyperscale serverless via Azure CLI
az sql db update
  --resource-group YourResourceGroup
  --server YourServerName
  --name YourDatabaseName
  --edition Hyperscale
  --service-objective HS_Gen5_2   -- minimum compute
  --compute-model Serverless
  --min-capacity 0.5
  --max-capacity 4
  --auto-pause-delay 60           -- auto-pause after 60 minutes idle

-- Verify the migration completed
SELECT
    DATABASEPROPERTYEX(DB_NAME(), 'ServiceObjective') AS NewServiceObjective,
    DATABASEPROPERTYEX(DB_NAME(), 'Edition')          AS NewEdition;

Migration From On-Premises SQL Server

Migrating from on-premises SQL Server to Hyperscale follows the same paths as migration to any Azure SQL Database tier: Azure Database Migration Service, backup and restore to URL (for eligible versions), transactional replication, or manual BACPAC export and import. The same T-SQL compatibility considerations apply as with any Azure SQL Database migration. Most T-SQL code runs without modification.

References

• Microsoft Docs: Hyperscale Service Tier Overview
• Microsoft Docs: Hyperscale Distributed Functions Architecture
• Microsoft Docs: Azure SQL Database Hyperscale FAQ
• Microsoft Docs: Hyperscale Secondary Replicas
• Microsoft Tech Community: Azure SQL Database Hyperscale Simplified Pricing (March 2025)
• Microsoft Azure: Azure SQL Database Pricing
• Microsoft Docs: General Purpose Service Tier
• Microsoft Docs: Business Critical Service Tier
• SQLYARD: SQL Server Pricing and Licensing Guide 2026
• SQLYARD: From Rows to Reasoning: Designing SQL Server Databases for AI Apps and Agents