Hyperscale

Not every Harrow & Finch database is small. SalesHistory, the database behind every multi-year sales report the company produces, holds every till line since 2012: about 3.2 TB today, growing by about 350 GB a year, and expected to grow faster once online orders and loyalty data are added. On HF-SQL01 it lives on the SAN whose support contract ends in June 2027. Restoring it from backup takes most of a day, which is why Walt has never actually tested a full restore. Keiko and Ines want to query it for the planned Finch Data Hub. And it is too large for comfort in General Purpose or Business Critical, whose maximum sizes are measured in single-digit terabytes. Elena proposes Hyperscale, and this lesson explains why.

A different architecture

In the other service tiers, compute and storage are tied together: General Purpose attaches remote storage to one compute node, and Business Critical copies all the data to every replica's local SSD. Hyperscale splits the database engine into separately scaled parts. Compute nodes run the query processor and hold a large local cache, using fast local SSD as an extension of memory called the resilient buffer pool extension. Page servers each own a range of the database's data pages, keep them up to date, and serve them to compute nodes on request. A log service receives the transaction log from the primary compute node, makes it durable, and feeds it to the page servers and the secondary replicas. Underneath everything, the data files live in Azure Storage, which also holds the snapshots used for backups.

Because the parts are separate, Hyperscale behaves differently from the other tiers in ways that matter to a DBA. The database can grow to 128 TB, adding page servers as it grows. Compute can be scaled up or down in minutes, whatever the database size, because the new compute node does not need its own copy of the data. Backups are snapshots of the files in Azure Storage, taken almost instantly with no load on compute, and restores of very large databases complete in minutes to a few hours rather than a day, because a restore creates new files from snapshots in parallel. And replicas can be added quickly, since they also read from the shared page servers.

Replicas in Hyperscale

Hyperscale offers three kinds of secondary replica, and the exam expects you to tell them apart. High-availability replicas are hot standbys in the same region that share the primary's page servers. You can have up to four; if the primary fails, one of them takes over in seconds, and they can serve read-only connections with ApplicationIntent=ReadOnly. Named replicas also share the primary's page servers, but they appear as separate databases with their own names, their own sizes and their own security, so a reporting team can have an isolated replica sized for its workload; a database can have many named replicas. Geo-replicas live in another region and have their own page servers there, providing disaster recovery like active geo-replication in the other tiers, which MSAZ-282 covers.

For SalesHistory, Elena's design uses one high-availability replica for resilience and one named replica, SalesHistory_reports, sized separately for Keiko's reporting and the Data Hub's extraction jobs. The heavy month-end queries then run on the named replica, with their own compute, and never touch the primary that receives each night's load from StockLine.

-- Run in master on the logical server that will hold the named replica.
ALTER DATABASE SalesHistory
    ADD SECONDARY ON SERVER [hf-sql-history-prod-cus]
    WITH (SECONDARY_TYPE = NAMED, DATABASE_NAME = [SalesHistory_reports]);

-- The named replica can then be scaled on its own:
ALTER DATABASE SalesHistory_reports MODIFY (SERVICE_OBJECTIVE = 'HS_Gen5_8');

Pricing and sizing

Hyperscale compute is billed per vCore like the other vCore tiers, for the primary and for each replica. Storage is billed for the space actually used, not for a maximum you reserve, because the database grows automatically. Backup storage is billed for the snapshot and log space beyond what the service includes. Microsoft simplified Hyperscale pricing in recent years so that it is often comparable with General Purpose for the same vCores, which has made it a common choice even for medium-sized databases that may grow; Walt checks the current rates in the pricing calculator rather than relying on older blog posts. Hyperscale also offers serverless compute, which scales between a minimum and a maximum like serverless General Purpose; auto-pause for Hyperscale serverless was still a preview feature when Walt checked in November 2026.

Moving into and out of Hyperscale

An existing Azure SQL database moves to Hyperscale with a normal scaling command, and the move is online: data is copied into the Hyperscale storage while the database keeps working, and a short switch happens at the end. Large databases take hours to copy, so the operation should run during a quiet period. For a long time, moving to Hyperscale was one way. Today a database that moved from another tier can be moved back to General Purpose within 45 days of its migration to Hyperscale, which gives a safety net if testing goes badly. A database created directly in Hyperscale cannot move to another tier; it must be exported or copied with other tools.

az sql db update --name SalesHistory --server hf-sql-history-prod-cus --resource-group rg-history-prod-cus --edition Hyperscale --family Gen5 --capacity 8 --ha-replicas 1

SalesHistory, though, is on premises, and Azure SQL Database cannot restore a native SQL Server backup. Walt's migration plan for it uses the Database Migration Service in offline mode, which copies the schema and data into a new Hyperscale database over a weekend, followed by a short catch-up of the days loaded since. Downtime matters less here than for StockLine, because SalesHistory is loaded once a night and read by reports; a weekend without fresh history reports is acceptable to the business.

Testing a restore

Walt's first Hyperscale task after the migration will be the full restore test he has never managed on premises. A point-in-time restore of an Azure SQL database always creates a new database, on the same logical server or another one in the region, rather than overwriting the original, so the test does no harm. For Hyperscale, the restore copies storage snapshots and replays only the log needed to reach the chosen moment, so its duration depends far more on the amount of log than on the size of the data. Walt's plan is to restore SalesHistory to the state it was in at 6:00 one morning, as a new database called SalesHistory_restoretest, record how long the restore takes, run a set of row counts and checksums on the five largest tables against the original, and then delete the copy so it stops costing money.

What is different in Hyperscale

Hyperscale supports the same T-SQL and most of the same features as the other tiers, but a few behaviors differ and appear in exam questions. Backups are snapshot-based, so point-in-time restore is fast and does not depend on database size, and long-term retention is supported. Because storage grows automatically, there is no maximum data size to manage, although the space used is billed. Very large single transactions are limited by the log service's throughput, which is high but not unlimited, so a massive data load should be done in batches. And a few features, such as some cross-database options available on Managed Instance, do not apply because Hyperscale is part of SQL Database.

Hyperscale elastic pools let several Hyperscale databases share compute, which suits a software provider with many large tenants. Harrow & Finch has only one Hyperscale candidate, so it uses a single database.

Choosing Hyperscale

Elena gives Walt a short checklist for recommending Hyperscale. Choose it when a database is already large, or likely to become large, so that General Purpose and Business Critical size limits would become a problem. Choose it when fast restores of a large database matter for recovery objectives, because snapshot restores are much faster than restoring a full backup. Choose it when compute needs change often and must change quickly, or when reporting needs independent replicas. Prefer another tier when the database is small and will stay small, when it needs Managed Instance features such as SQL Server Agent or cross-database queries, or when the application depends on the lowest possible commit latency of Business Critical's local storage.

SalesHistory meets the first three tests and fails none of the last ones. Walt writes Hyperscale into the plan, with the named replica for reports, and puts a full restore test into the first month after migration, the test he has never been able to run on premises.