Introducing Azure SQL Database Hyperscale Service Tier

Ifyour current SQL Database service tier is not well suited to yourneeds, I’m excited to tell you about a newly created service tier inAzure called Hyperscale. Hyperscale is a highly scalable storage andcompute performance tier that leverages the Azure architecture to scaleout resources for Azure SQL Database beyond the current limitations ofgeneral purpose and business critical service tiers.

The Hyperscale service tier provides the following capabilities:

• Support for up to 100 terabytes of database size (and this will grow over time)
• Faster large database backups which are based on file snapshots
• Faster database restores (also based on file snapshots)
• Higher overall performance due to higher log throughput and faster transaction commit time regardless of the data volumes
• The ability to rapidly scale out. You can provision one or more readonly nodes for offloading your read workload for use as hot standbys.
• You can rapidly scale up your compute resources (in constant time)to accommodate heavy workloads, so you can scale compute up and down asneeded just like Azure Data Warehouse

Who should consider moving over to the Hyperscale tier? This is notan inexpensive tier, but it’s a great choice for companies who havelarge databases and have not been able to use Azure databases in thepast due to its 4-terabyte limit, as well as for customers who seeperformance and scalability limitations with the other 2 service tiers.

It is primarily designed for transactional or OLTP workloads.However, it does support hybrid and OLAP workloads, but something tokeep in mind when designing out your databases and services. It’s alsoimportant to note that elastic pools do not support the Hyperscaleservice tier.

How does it work?

• You separate the compute and storage out into 4 separate nodes similar to Azure Data Warehouse.
• The compute node is where the relational engine lives or where the querying process happens.
• The page server node is where the scaled-out storage engine residesand where database pages are served out to the compute nodes on demandand keeps pages updated as transactions update data, so these nodes aremoving the data around for you.
• The log service node is where the log records are kept as they comein from the compute node and kept in a durable cache, then they’reforwarded along to additional compute nodes and caches to ensureconsistency. When all this is spread out and everything is consistentlyspread across the compute nodes, it will get stored in Azure storage forlong term storage of your logs.
• Lastly, the Azure storage node is where all the data is pushed fromthe page servers. So, all the data that eventually lands in the databasegets pushed over to Azure storage and this is also the storage thatgets used for backups, as well as where the replication betweenavailability groups happens.

This Hyperscale tier is an exciting opportunity for those customersthat don’t have their requirements fulfilled with prior service tiers.It’s another great Microsoft offering that’s worth checking out if youhave had these service tier issues up to now. And it helps to leave aline of distinction between Azure Data Warehouse and Azure Databasebecause you now can scale out/up and tons of data, but it’s still builtout for the transactional processing, as opposed to Azure Data Warehousewhich is more of the analytical or massively parallel processing.