Hyperscale service tier is available for single databases that are using vCore-based purchasing model. But, before you start thinking much about this tier, let’s first understand what actually this “Hyperscale” is? And to understand this, let’s recall that an Azure SQL database can go upto 4TB in size under a standard deployment. What if you have databases which are going beyond this limit?
This is where Hyperscale tier comes to your rescue. It has been tested with databases upto 100TB though there is NO technical limitation and Microsoft encourages you to test this even with larger databases. The architecture behind Hyperscale technology takes advantage of cheap storage and flexible compute power. Just like Azure Synapse Analytics separates storage from computer, similarly, Azure SQL Database Hyperscale does it. However, the storage is not distributed here. The architecture still operates on SMP approach whereby having one linear storage and one compute resource. Storage is still held at a single place and is written by a single master compute node.
The compute node has caches built on SSD drives for faster page fetchings and these are called Resilient Buffer Pool Extensions (RBPEX). You also must be wondering that having a single compute node but database going over 100 TBs also, how the impact on performance is managed. Under this architecture, compute node is supported by page servers whereby each page server is allocated 1TB of space at maximum and there is no limit on the number of page servers. So, this way, irrespective of database size, each page server is dealing with only 1TB of data at any point of time and manages the performance well.
The same concept applies to when it comes to restoring a multi TB size database i.e. it makes no difference whether your database is 100TB or 1TB. Page server restores its own portion of 1TB very quickly.
However, it has some limitations too –
- While provisioning this, you will see this warning that once provisioned, you can not change the tier
- Hyperscale tier is currently available for Azure SQL Database, not for Managed Instance
- Elastic pool do not support Hyperscale tier
It has some interesting points about its pricing too –
- For compute, in addition to the number of vCores you selected, additionally, it’s priced per-replica. By default, one primary and one read-only replica is created when you provision it. You may go upto 5 read-only replicas (1 primary and 4 secondary)
- For storage, it’s per GB cost as usual though you don’t specify the maximum size of database neeeded here. Storage is automatically allocated between 40GB and 100TB in 10GB increments. But you don’t need to worry as you are charged only for the used space, not the allocated space
- Its secondary replica mechanism causes the total cost to be high as compared to regular or standard vCore-based deployments