Elastic pools for Azure SQL Database Hyperscale now Generally Available!
Published Sep 12 2024 08:00 AM 2,876 Views

We are very pleased to announce General Availability (GA) for Azure SQL Database Hyperscale elastic pools (“Hyperscale elastic pools”).

 

Why use Hyperscale elastic pools?

 

Azure SQL Database is the preferred database technology for hundreds of thousands of customers. Built on top of the rock-solid SQL Server engine and leveraging leading cloud-native architecture and technologies, Azure SQL Database Hyperscale offers leading performance, scalability and elasticity with one of the lowest TCO in the industry .

 

While you may start with a standalone Hyperscale database, chances are that as your fleet of databases grows, you want to optimize price and performance across a set of Hyperscale databases. Elastic pools offer the convenience of pooling resources like CPU, memory, IO, while ensuring strong security isolation between those databases.

 

Here's an example showing 8 standalone databases, each with an individually variable workload. Each database tends to spike in resource consumption at different points in time. Each database must therefore be allocated adequate resources (CPU, data IO, log IO, etc.) to accommodate the individual peak resource requirement. Accordingly, the total cost of these databases is directly proportional to the number of databases, while the average utilization of each database is low.

 

Arvind_Shyamsundar_0-1726086980267.png

vCore configuration shown is for demonstration purposes. Prices as of Sep 12, 2024, and only represent compute costs for Azure East US. Storage costs are extra and are billed per database. Actual configuration depends on workload profiles and performance requirements.

 

With the shared resource model offered by Hyperscale elastic pools, the aggregate performance requirements of the workloads become much “smoother”, as seen in the white line chart. Correspondingly, the elastic pool only needs to be provisioned for the maximum combined resource requirement. This way, overall cost is lower, and average resource utilization is much higher than the standalone database scenario.

 

Arvind_Shyamsundar_1-1726086980270.png

vCore configuration shown is for demonstration purposes. Prices as of Sep 12, 2024, and only represent compute costs for Azure East US. Savings are indicative. Storage costs are extra and billed per database. Actual configuration depends on workload profiles and performance requirements.

 

Customer feedback

 

For many customers, elastic pools are an essential tool to stay competitive from price and performance perspectives. Adam Wiedenhaefer, Principal Data Architect, Covetrus Global Technology Solutions, says:

 

"Elastic pools on Azure SQL Database Hyperscale has provided us a solid blend between performance, storage, and overall flexibility. This allows us to scale our systems in ways we couldn't before at a price point that reduces overall costs, savings we can pass on to Covetrus customers."

 

The cloud-native architecture for Hyperscale elastic pools enables independent scaling of compute and storage in a fast and predictable manner. This allows customers to perfectly optimize their compute resources while relying on auto-scaling storage, which provides hands-off scalability and great performance as their databases grow. Nick Olsen, CTO, ResMan says:

 

We have been users of Azure SQL Database elastic pools for over a decade now and have loved the ability to share resources amongst many databases. Our applications are such that only a few databases reach peak utilization simultaneously but we need to allow any given database to consume quite a bit of resources when bursts occur.  As our requirements evolved, we found that we needed to go beyond the resource limits of our existing pools while controlling for the amount of time it would take to scale very large pools.  The introduction of elastic pools in Azure SQL Database Hyperscale introduced much higher limits on pool size and the ability to scale in constant time, regardless of the size of the workload.  We are now able meet the evolving needs of our business while allowing us to achieve greater cost savings than we have had in the past.

 

Throughout public preview, we have received overwhelmingly positive feedback from several customers about the superb reliability, great performance and scalability, and the value for money that Hyperscale elastic pools have provided. Many customers are already running production systems on Hyperscale elastic pools since public preview.

 

Availability

 

During a very successful public preview, we have seen tremendous adoption from many customers and have addressed top customer requests and improvements including:

 

 

All these capabilities for Hyperscale elastic pools are also Generally Available (GA) starting 12 September 2024. Hyperscale elastic pools are available in all supported Azure regions including US Government regions and Azure China.

 

Pricing

 

With GA we are also adjusting the pricing for Hyperscale elastic pools. Starting 12 September 2024, we will begin charging an additional $0.05 / vCore / hour for each Hyperscale elastic pool, compared to the preview price. The additional charge will not be eligible for reserved capacity discounts and will apply to the primary pool replica and any secondary pool replicas configured. The updated pricing for Azure public regions and US Government regions is visible in the Azure portal, the Azure Pricing calculator and on the Azure SQL Database pricing page. It is not yet updated for Azure China due to a known limitation.

 

Resources

 

Here's a quick video summarizing the value proposition, and the typical scenarios for Hyperscale elastic pools:

 

 

For even more information:

 

Our team is here to assist with any questions you may have. Please leave a comment on this blog and we’ll be happy to get back to you. Alternatively, you can also email us at sqlhsfeedback AT microsoft DOT com. We are eager to hear from you all!

Version history
Last update:
‎Oct 04 2024 03:09 PM
Updated by: