We are thrilled to announce a set of significant updates to Azure SQL Database Hyperscale. These updates are designed to provide more scalability, faster data processing, and improved reliability, particularly during failovers

Increased maximum database size

We are pleased to announce that the maximum database size in Azure SQL Database Hyperscale has increased from 100 TiB to 128 TiB. This enhancement is now generally available (GA) for single Hyperscale databases and will be released later for Hyperscale elastic pools. This expansion allows for even greater flexibility and capacity to manage large datasets, accommodating the needs of businesses with substantial data storage requirements.

Higher limits for transaction log generation rate

In our continuous effort to improve performance, the log generation rate in Azure SQL Database Hyperscale has been increased from 100 MiB/s to 150 MiB/s. The increased limit for the transaction log generation rate limit is currently in limited public preview, and you can sign up using this form: link.

The higher log generation rate means faster data processing and better handling of write-intensive workloads. This ensures that your applications run smoothly and efficiently, even during peak usage times. Whether you're dealing with bulk data inserts, high-volume transaction processing, real-time data ingestion, or rebuilding of large indexes, the enhanced log generation rate provides the performance boost needed to keep your systems responsive and reliable.

Continuous priming

One another new feature we are introducing is continuous priming. This innovative feature is designed to optimize performance during failovers by priming secondary compute replicas. Here’s how it works:

• Continuous priming collects information about the most frequently accessed pages in all Hyperscale compute replicas, both primary and secondary.
• This information is aggregated at the Hyperscale storage layer (page servers).
• All Hyperscale compute replicas then use this list of most frequently accessed pages, which represents the typical customer workload, to “prime” both the buffer pool (BP) and the resilient buffer pool extension (RBPEX) with any missing pages.
• This “priming” process is done continuously to keep up with changes in the customer work set.

With continuous priming, local HA replicas will prime themselves with the pages being used in the primary replica. This ensures that performance remains consistent and optimized, even during failovers. Please note that continuous priming is not applicable to Hyperscale databases with serverless compute and named replicas. If you’re interested in enrolling in this preview, please sign up using the provided link.

Conclusion

We are confident that these new features and enhancements will significantly benefit your operations, providing more scalability, faster data processing, and greater reliability. Stay tuned for more updates as we continue to innovate and improve Azure Database Hyperscale to meet your needs. Please share your feedback and questions by leaving a comment; you can also email us at sqlhsfeedback AT microsoft DOT com. We are eager to hear from you all!