1024px-Microsoft_Azure_LogoAzure SQL Database has a new service tier called Hyperscale. Hyperscale is currently in public preview and offers the ability to scale past the 4TB limit for Azure SQL Database. Hyperscale is only available in the vCore-based purchasing model.

Hyperscale offers customers a highly scalable storage and computer performance tier that is built on the Azure architecture in order to scale out the storage and compute for an Azure SQL Database. By separating out the storage and compute, Hyperscale allows for scaling out storage limits well beyond what is available in the General Purpose and Business Critical service tiers.

You’ve probably already figured out that Hyperscale is primarily intended for those customers who are using or would like to use Azure SQL Database but have massive storage requirements. Currently Hyperscale has been tested with a database up to 100TB. That’s correct, you can have up to a 100TB Azure SQL Database, well currently in preview only right now. While Hyperscale is primarily optimized for OLTP workloads, it also supports hybrid and analytical workloads.

With Hyperscale offering databases up to 100TB (this is what Microsoft has tested up to so far), backups could be problematic to make. Microsoft offers near instantaneous database backups for Hyperscale leveraging file snapshots stored in Azure Blob storage. This is done with no IO impact on compute and regardless of the size of the database. This also offers fast database restores. I’ve seen a 40+ TB restore that took minutes!

Hyperscale offers rapid scale out, meaning within the Azure Portal you can configure up to 4 read-only nodes for offloading your read workload, these can also be used as hot-standbys. At the same time, you can scale up compute resources to handle heavy workloads. This can be done in constant time. When you no longer need the scaled-up compute resources, scale back down. You can also expect higher overall performance with Hyperscale due to higher log throughput and much faster transaction commit times no matter the size of your database.

While Hyperscale is in public preview, it is strongly recommended to not run any production workload yet. The reason for this is because current once you migrate to Hyperscale, you can move back to General Purpose or Business Critical tiers. For testing Hyperscale you should make a copy of your production database and migrate it to the Hyperscale service tier.