The ability to scale out a database is a key feature for a modern solution, allowing it to adapt easily and quickly to varying workloads. From implementing complex massive scale-out scenarios that handle highly concurrent OLTP requests, to highly performing HTAP solutions that analyze incoming data in near-real time and with minimum data transformation overhead, elasticity is a winning factor.
Capabilities
Today with the introduction of Azure SQL Hyperscale named replicas, it is possible to create up to 30 secondary read-only replicas that:
- Appear as regular (read-only) Azure SQL databases in the portal and in API (CLI, PowerShell, T-SQL) calls.
- Can have a database name different from the primary replica, and optionally be located on a different logical server.
- Have their own Service Level Objective that can be set and changed independently from the primary replica.
- Support different authentication and authorization for each named replica by creating different logins on logical servers hosting named replicas.
- Use Azure Hybrid Benefit: it is possible to save a substantial amount of money by taking advantage of the ability to scale-out instead of scaling-up.
Named replicas take advantage of Hyperscale native cloud architecture, so that a database replica is created without copying data around. As a result, a named replica can usually be created in less than a minute, no matter the size of the primary database.
Use Cases
The main goal of named replicas is to allow massive OLTP read scale-out scenario and to improve Hybrid Transactional and Analytical Processing (HTAP) workloads.
Aside from the main scenarios listed above, named replicas offer flexibility and elasticity to also satisfy many other use cases:
- Access Isolation: grant a login access to a named replica only and deny it from accessing the primary replica or other named replicas.
- Workload-Dependent Service Objective: as a named replica can have its own service level objective, it is possible to use different named replicas for different workloads and use cases. For example, one named replica could be used to serve Power BI requests, while another can be used to serve data to Apache Spark for Data Science tasks. Each one can have an independent service level objective and scale independently.
Workload-Dependent Routing: with up to 30 named replicas, it is possible allowing workload isolation even within the same solution. For example, four named replicas could be used to serve requests coming from mobile applications, while other two named replicas can be used to serve requests coming from a web application. This approach would allow a fine-grained tuning of performance and costs for each use case: taking advantage of the ability to easily and quickly create named replicas, their number can be adjusted over time to keep the performance and cost ratio always at optimum level.
User Experience
Azure SQL Hyperscale named replicas in all regions where Azure SQL Hyperscale is available. They can be created from the portal, using the new Replica blade available for each database:
This new Replica blade has been introduced to harmonize the user experience for all types of secondary replicas, including named replicas and geo replicas. Beside the portal, full support for named replicas has been added also via REST API, Powershell or AZ CLI.
Customer Stories
Some customers already started using Named Replicas with great success. Watch this video to see how Xplor built a fast, scalable data system on Azure SQL Hyperscale.
Next Steps
More details on Azure SQL Hyperscale named replicas, the related use cases, and general information on all secondary replicas supported by Azure SQL Hyperscale here: Hyperscale secondary replicas.
You’ll find full documentation, samples with GitHub repo ready to be used, along with answers to common FAQ, so that you can start to take advantage of Azure SQL Hyperscale named replicas right away.