August 1, 2021 1 min read

Azure SQL Hyperscale: The Ultimate Database Scaling Solution

I wrote “Azure SQL Hyperscale: The Ultimate Database Scaling Solution” to share practical, production-minded guidance on this topic.

What Makes Hyperscale Different?

Traditional database architectures couple compute and storage tightly together. Hyperscale breaks this coupling by introducing a distributed storage architecture with page servers, log service, and a decoupled compute layer.

Key Architecture Components

Compute Replicas: Handle query processing
Page Servers: Store and serve data pages
Log Service: Manages transaction log
Azure Storage: Provides durable blob storage

Creating a Hyperscale Database

-- Create a Hyperscale database using T-SQL
CREATE DATABASE HyperscaleDB
(
    EDITION = 'Hyperscale',
    SERVICE_OBJECTIVE = 'HS_Gen5_4',
    MAXSIZE = 100 TB
);

Using Azure CLI:

# Create a Hyperscale database
az sql db create \
    --resource-group myResourceGroup \
    --server myserver \
    --name HyperscaleDB \
    --edition Hyperscale \
    --family Gen5 \
    --capacity 4 \
    --zone-redundant false

Scaling Compute Independently

One of Hyperscale’s greatest strengths is the ability to scale compute without moving data:

# Scale up compute
az sql db update \
    --resource-group myResourceGroup \
    --server myserver \
    --name HyperscaleDB \
    --service-objective HS_Gen5_8

Adding Read Replicas

Hyperscale supports up to 4 read replicas for read-heavy workloads:

# Add read replicas
az sql db update \
    --resource-group myResourceGroup \
    --server myserver \
    --name HyperscaleDB \
    --read-replicas 2

// Connect to a read replica in C#
var connectionString = "Server=myserver.database.windows.net;" +
    "Database=HyperscaleDB;" +
    "Authentication=Active Directory Integrated;" +
    "ApplicationIntent=ReadOnly;";

using var connection = new SqlConnection(connectionString);
await connection.OpenAsync();

Near-Instant Backups

Hyperscale uses snapshot-based backups that complete in minutes regardless of database size:

-- Check backup history
SELECT
    database_name,
    backup_start_date,
    backup_finish_date,
    DATEDIFF(SECOND, backup_start_date, backup_finish_date) AS duration_seconds
FROM msdb.dbo.backupset
ORDER BY backup_finish_date DESC;

Point-in-Time Restore

Restore to any point within retention period:

# Restore to a specific point in time
az sql db restore \
    --resource-group myResourceGroup \
    --server myserver \
    --name HyperscaleDB-Restored \
    --source-database HyperscaleDB \
    --edition Hyperscale \
    --service-objective HS_Gen5_4 \
    --time "2021-08-01T10:00:00Z"

When to Choose Hyperscale

Hyperscale is ideal for:

Databases exceeding 4 TB
Workloads requiring fast scaling
Applications needing read replicas
Systems requiring rapid backup/restore

Performance Monitoring

-- Monitor Hyperscale-specific DMVs
SELECT
    database_id,
    page_server_reads,
    page_server_read_bytes,
    snapshot_commit_lsn
FROM sys.dm_database_page_allocations;

-- Check replica status
SELECT
    replica_id,
    synchronization_state_desc,
    synchronization_health_desc
FROM sys.dm_hadr_database_replica_states;

Hyperscale transforms how enterprises approach database scalability, offering cloud-native features that were previously impossible with traditional SQL Server deployments.\n\n## Takeaways\n\nAdd a concise, personal takeaway and recommended next steps here.\n