service-tier-hyperscale-frequently-asked-questions-faq.yml

### YamlMime:FAQ
metadata:
  title: Azure SQL Database Hyperscale FAQ
  description: Answers to common questions customers ask about a database in SQL Database in the Hyperscale service tier - commonly called a Hyperscale database.
  services: sql-database
  ms.service: azure-sql-database
  ms.subservice: service-overview
  ms.custom: sqldbrb=1, build-2025
  ms.devlang: 
  ms.topic: faq
  author: WilliamDAssafMSFT
  ms.author: wiassaf
  ms.reviewer: dfurman, mathoma, dinethi, adbadram
  ms.date: 08/11/2025
title: Azure SQL Database Hyperscale FAQ
summary: |
  [!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]
  
  This article provides answers to frequently asked questions for customers considering a database in the Azure SQL Database Hyperscale service tier, referred to as just Hyperscale in the remainder of this FAQ. This article describes the scenarios that Hyperscale supports and the features that are compatible with Hyperscale.
  
  - This FAQ is intended for readers who have a brief understanding of the Hyperscale service tier and are looking to have their specific questions and concerns answered.
  - This FAQ isn't meant to be a guidebook or answer questions on how to use a Hyperscale database. For an introduction to Hyperscale, see [Azure SQL Database Hyperscale](service-tier-hyperscale.md).
  

sections:
  - name: General questions
    questions:
      - question: |
          What is a Hyperscale database?
        answer: |
          A Hyperscale database is a database in Azure SQL Database that is backed by the Hyperscale [scale-out storage technology](hyperscale-architecture.md). A Hyperscale database supports up to 128 TB of data and provides high throughput and performance, as well as rapid scaling to adapt to the workload requirements. Connectivity, query processing, database engine features, and so on, work like in any other database in Azure SQL Database.

      - question: |
          What compute tiers and purchasing models support Hyperscale?
        answer: |
          The Hyperscale service tier is available for single databases (both provisioned and serverless) and for elastic pools using the vCore-based purchasing model. It is not available in the DTU-based purchasing model.

      - question: |
          How does the Hyperscale service tier differ from the General Purpose and Business Critical service tiers?
        answer: |
          The vCore-based service tiers are differentiated based on database availability and storage type, performance, and maximum storage size as described in [resource limit comparison](service-tier-hyperscale.md#compare-resource-limits). 
                   
      - question: |
          Who should use the Hyperscale service tier?
        answer: |
          The Hyperscale service tier is for all customers looking for higher performance and availability, fast backup and restores, fast storage, and compute scalability. This includes customers who are starting out small and growing, those running large mission-critical databases, those who are moving to the cloud to modernize their applications and customers who are already using other service tiers in Azure SQL Database.
          
          With Hyperscale, you get:
          
          - Database size that can grow from 10 GB up to 128 TB, irrespective of the compute size.
          - Compute vCore resources from 2 vCores up to 128 vCores.
          - Fast database backups regardless of database size (backups are based on storage snapshots).
          - Fast database restores regardless of database size (restores are from storage snapshots).
          - Higher transaction log throughput regardless of database size and the number of vCores.
          - Read Scale-out using one or more read-only replicas, used for offloading read-only workloads or as hot standby databases.
          - Rapid scaling up of compute, in constant time, to be more powerful to accommodate the heavy workload and then scale down, in constant time. Scaling operations take single-digit minutes for provisioned compute, and less than a second for serverless compute, regardless of database size.
          - The option to pay for what you use with serverless compute, where compute is billed based on usage.

      - question: |
          What regions currently support Hyperscale?
        answer: |
          The Hyperscale service tier is available in all regions where Azure SQL Database is available.
          
      - question: |
          Can I create multiple Hyperscale databases per server?
        answer: |
          Yes. For more information and limits on the number of databases per server, see [SQL Database resource limits for single and pooled databases on a server](resource-limits-logical-server.md).
          
      - question: |
          What are the performance characteristics of a Hyperscale database?
        answer: |
          The Hyperscale architecture provides high performance and throughput while supporting large database sizes.

      - question: |
          What is the scalability of a Hyperscale database?
        answer: |
          Hyperscale provides rapid scalability based on your workload demand.
          
          - **Scaling Up/Down**
          
            With Hyperscale, you can scale up the primary compute size in terms of resources like CPU and memory, and then scale down, in constant time. Because the storage is remote, scaling up and scaling down isn't a size-of-data operation.

            Support for [serverless compute](serverless-tier-overview.md) provides automatic scale-up and scale-down and compute billing based on usage.

          - **Scaling In/Out**
          
            With Hyperscale, you can use three kinds of secondary replicas to cater to read scale-out, high availability, and geo-replication requirements. This includes:
            - Up to four [high-availability replicas](service-tier-hyperscale-replicas.md#high-availability-replica) having the same compute size as primary. These serve as hot standby replicas to quickly fail over from the primary. You can also use them to offload read workloads from the primary.
            - Up to 30 [named replicas](service-tier-hyperscale-replicas.md#named-replica) having the same or different compute size than the primary, to cater to various read scale-out scenarios.
            - A [geo-replica](service-tier-hyperscale-replicas.md#geo-replica) in a different Azure region to protect against regional outages and to enable geographic read scale-out.
          
  - name: Deep dive questions
    questions:
      - question: |
          Can I mix Hyperscale and non-Hyperscale databases on the same SQL logical server?
        answer: |
          Yes, you can.

      - question: |
          Does Hyperscale require my application programming model to change?
        answer: |
          No, your application programming model stays the same as for any other MSSQL database. You use your connection string as usual and the other regular ways to interact with your Hyperscale database. Once your application is using the Hyperscale database, your application can take advantage of features such as [secondary replicas](service-tier-hyperscale-replicas.md).

      - question: |
          What transaction isolation level is the default in a Hyperscale database?
        answer: |
          On the primary replica, the default transaction isolation level is `READ COMMITTED` with the `READ_COMMITTED_SNAPSHOT` database option (RCSI) enabled. On the secondary replicas, the isolation level is `SNAPSHOT`. This is the same as in any other Azure SQL database.

      - question: |
          Can I bring my on-premises or IaaS SQL Server license to Hyperscale?
        answer: |
          With the new, simplified pricing in effect since December 15, 2023, the price of compute has been reduced for newly created Hyperscale databases, all serverless Hyperscale databases, and all Hyperscale elastic pools. With the new, simplified pricing, there's no need to apply Azure Hybrid Benefit (AHB) to obtain equivalent savings. Azure Hybrid Benefit (AHB) can only be applied to older (created before December 15, 2023) Hyperscale single databases with provisioned compute. For those older databases, AHB is only applicable until December 2026, after which those databases will also be billed as per the new, simplified pricing.

          For more information, see [Hyperscale pricing blog](https://aka.ms/hsignite2023) and [Azure SQL Database Hyperscale - lower, simplified pricing](https://aka.ms/hsprice2023).
          
      - question: |
          What kind of workloads is Hyperscale designed for?
        answer: |
          Hyperscale works well for all workload types, including OLTP, Hybrid (HTAP), and Analytical (data mart) workloads.

      - question: |
          How can I choose between Azure Synapse Analytics and Azure SQL Database Hyperscale?
        answer: |
          If you're currently running interactive analytics queries using SQL Server as a data warehouse, Hyperscale is a great option because you can host small and mid-size data warehouses (such as a few TB up to 128 TB) at a lower cost, and you can migrate your SQL Server data warehouse workloads to Hyperscale with minimal T-SQL code changes.
          
          If you're running data analytics on a large scale with complex queries and sustained ingestion rates higher than 100 MiB/s or using Parallel Data Warehouse (PDW), Teradata, or other Massively Parallel Processing (MPP) data warehouses such as Azure Synapse Analytics, then Microsoft Fabric could be the best choice.

          Ingestion or log generation rate is 150 MiB/s per database for premium-series and premium-series memory optimized hardware of Azure SQL Database Hyperscale. For standard-series hardware, the maximum log rate is 100 MiB/s per database. For elastic pools, the maximum log rate is 150 MiB/s per pool for premium-series and premium-series memory optimized hardware, and 125 MiB/s per pool for other hardware.

  - name: Hyperscale compute questions
    questions:
      - question: |
          Can I pause my compute at any time?
        answer: |
          Not at this time. However you can scale your compute and the number of replicas down to reduce cost during nonpeak times, or use [serverless](serverless-tier-overview.md) to automatically scale compute based on usage. 

      - question: |
          Can I provision a compute replica with extra RAM for my memory-intensive workload?
        answer: |
          For read workloads, you can create a [named replica](service-tier-hyperscale-replicas.md#named-replica) with a higher compute size (more cores and memory) than the primary. For more information on available compute sizes, see [Hyperscale storage and compute sizes](resource-limits-vcore-single-databases.md#hyperscale---provisioned-compute---gen5).
          
      - question: |
          Can I provision multiple compute replicas of different sizes?
        answer: |
          For read workloads, this can be achieved using [named replicas](service-tier-hyperscale-replicas.md#named-replica).

      - question: |
          How many Read Scale-out replicas are supported?
        answer: |
          You can scale the number of HA secondary replicas between 0 and 4 using [Azure portal](https://portal.azure.com) or [REST API](/rest/api/sql/databases/create-or-update). Additionally, you can create up to 30 [named replicas](service-tier-hyperscale-replicas.md#named-replica) for many read scale-out scenarios. Each named replica can have up to 4 HA secondary replicas.
          
      - question: |
          For high availability, do I need to provision additional compute replicas?
        answer: |
          In Hyperscale databases, data resiliency is provided at the storage level. You only need one replica (the primary) to provide resiliency. If the compute replica fails or is under maintenance, a new replica is created automatically with no data loss.
          
          However, if there's only the primary replica, it can take a minute or two to create a new replica, vs. seconds in the case when an HA secondary replica is available. The new replica will have cold caches initially, which can result in higher storage latency and reduced query performance immediately after failover.
          
          For mission-critical applications that require high availability with minimal failover impact, you should provision at least one HA secondary replica to ensure a hot standby replica is available to serve as a failover target.
          
  - name: Data size and storage questions
    questions:
      - question: |
          What is the maximum database size supported with Hyperscale?
        answer: The maximum size of a single Hyperscale database is currently 128 TB, irrespective of compute size. The maximum size of a database in a Hyperscale elastic pool is currently 100 TB.

      - question: |
          What is the size of the transaction log with Hyperscale?
        answer: |
          In Hyperscale, the transaction log is practically infinite, with a restriction that the active portion of the log cannot exceed 1 TB. The active portion of the log can grow because of long-running transactions, or because of [Change Data Capture](change-data-capture-overview.md?view=azuresql-db&preserve-view=true) processing not keeping up with the rate of data change. Avoid unnecessarily long and large transactions to stay below this limit. Other than this restriction, you don't need to worry about running out of log space on a system that has high log throughput. However, log generation rate might be reduced for continuous aggressively writing workloads. Log generation rate of 150 MiB/s for premium-series and premium-series memory optimized hardware, and 100 MiB/s for other hardware.

      - question: |
          Does my tempdb scale as my database grows?
        answer: |
          Your `tempdb` database is located on local SSD storage and is sized proportionally to the compute size (the number of cores) that you provision. The size of `tempdb` isn't configurable and is managed for you. To determine maximum `tempdb` size for your database, see [Hyperscale storage and compute sizes](resource-limits-vcore-single-databases.md#hyperscale---provisioned-compute---gen5).

      - question: |
          Does my database size automatically grow, or do I have to manage the size of data files?
        answer: |
          Your database size automatically grows as you insert/ingest more data.

      - question: |
          What is the smallest database size that Hyperscale supports?
        answer: 10 GB. A Hyperscale database is created with a starting size of 10 GB and grows as needed.

      - question: |
          In what increments does my database size grow?
        answer: |
          Each data file grows by 10 GB. Multiple data files can grow at the same time.

      - question: |
          Is the storage in Hyperscale local or remote?
        answer: |
          In Hyperscale, data files are stored in Azure standard storage. Data is fully cached on local SSD storage, on page servers that are remote to compute replicas. In addition, compute replicas have data caches on local SSD and in memory, to reduce the frequency of fetching data from remote page servers.

      - question: |
          Can I manage or define files or filegroups with Hyperscale?
        answer: |
          No. Data files are added automatically to the `PRIMARY` filegroup. The common reasons for creating additional filegroups don't apply in the Hyperscale storage architecture, or in Azure SQL Database more broadly.

      - question: |
          Can I provision a hard cap on the data growth for my database?
        answer: |
          No.

      - question: |
          Is database shrink supported?
        answer: |
          Yes, [database and file shrink operations](file-space-manage.md) are supported in Azure SQL Database Hyperscale.

      - question: |
          Is data compression supported?
        answer: |
          Yes, just like in any other Azure SQL DB database. This includes row, page, and columnstore [compression](/sql/relational-databases/data-compression/data-compression).

      - question: |
          If I have a huge table, is table data spread out across multiple data files?
        answer: |
          Yes. The data pages associated with a given table can end up in multiple data files, which are all part of the same filegroup. The MSSQL database engine uses [proportional fill strategy](/sql/relational-databases/databases/database-files-and-filegroups#file-and-filegroup-fill-strategy) to distribute data over data files.
          
  - name: Data migration questions
    questions:
      - question: |
          Can I move my existing databases in Azure SQL Database to the Hyperscale service tier?
        answer: |
          Yes. For proofs of concept (POCs), we recommend you make a copy of your database and migrate the copy to Hyperscale. 

          The time required to move an existing database to Hyperscale consists of the time to copy data, and the time to replay the changes made in the source database while copying data. The data copy time is proportional to data size. The time to replay changes is shorter if the move is done during a period of low write activity.

          You can convert an existing Azure SQL Database to Hyperscale in the Azure portal, Azure CLI, PowerShell, and Transact-SQL. For more information, see [Convert an existing database to Hyperscale](convert-to-hyperscale.md).

          [Reverse migration](reverse-migrate-from-hyperscale.md) to the General Purpose service tier allows customers who have recently migrated an existing database in Azure SQL Database to the Hyperscale service tier to move back, should Hyperscale not meet their needs. While reverse migration is initiated by a service tier change, it's essentially a size-of-data operation between different architectures. Similarly to migration to Hyperscale, reverse migration is faster if done during a period of low write activity. For more information, see [Reverse migrate from Hyperscale](reverse-migrate-from-hyperscale.md).

      - question: |
          Can I move my Hyperscale databases to other service tiers?
        answer: |
          If you have previously migrated an existing Azure SQL Database to the Hyperscale service tier, you can reverse migrate it to the General Purpose service tier within 45 days of the original migration to Hyperscale. If you wish to migrate the database to another service tier, such as Business Critical, first reverse migrate to the General Purpose service tier, then modify the service tier. Reverse migration is a size-of-data operation.

          Databases created in the Hyperscale service tier can't be moved to other service tiers.
          
          Learn [how to reverse migrate from Hyperscale](reverse-migrate-from-hyperscale.md), including the [limitations for reverse migration](reverse-migrate-from-hyperscale.md#limitations-for-reverse-migration) and impacted [backup policies](reverse-migrate-from-hyperscale.md#backup-policies).

      - question: |
          Do I lose any functionality or capabilities after migration to the Hyperscale service tier?
        answer: |
          Yes. Some Azure SQL Database features are not supported in Hyperscale. If some of these features are enabled for your database, migration to Hyperscale could be blocked, or these features stop working after migration. For details, see [Known limitations](service-tier-hyperscale.md#known-limitations).

      - question: |
          Can I move my on-premises SQL Server database, or my SQL Server database in a cloud virtual machine to Hyperscale?
        answer: |
          Yes. You can use many existing migration technologies to migrate to Hyperscale, including transactional replication, and any other data movement technologies (Bulk Copy, Azure Data Factory, Azure Databricks, SSIS). See also the [Azure Database Migration Service](/azure/dms/dms-overview), which supports many migration scenarios.
          
      - question: |
          What is my downtime during migration from an on-premises or virtual machine environment to Hyperscale, and how can I minimize it?
        answer: |
          Downtime for migration to Hyperscale is the same as the downtime when you migrate your databases to other Azure SQL Database service tiers. You can use [transactional replication](replication-to-sql-database.md#data-migration-scenario) to minimize downtime migration for databases up to a few TB in size. For very large databases (10+ TB), you can consider implementing the migration process using ADF, Spark, or other bulk data movement technologies.
          
      - question: |
          How much time would it take to bring in X amount of data to Hyperscale?
        answer: |
          Hyperscale is capable of consuming up to 150 MiB/s of new/changed data, but the time needed to move data into databases in Azure SQL Database is also affected by available network throughput, source read speed, the type of load (bulk vs row-by-row), and the target database service level objective. 

      - question: |
          Can I read data from blob storage and do a fast load (like Polybase in Azure Synapse Analytics)?
        answer: |
          You can have a client application read data from Azure Storage and load data load into a Hyperscale database (just like you can with any other database in Azure SQL Database). Polybase is currently not supported in Azure SQL Database. As an alternative to provide fast load, use [Azure Data Factory](/azure/data-factory/index).
          
          It's also possible to bulk read data from Azure Blob store using BULK INSERT or OPENROWSET: [Examples of Bulk Access to Data in Azure Blob Storage](/sql/relational-databases/import-export/examples-of-bulk-access-to-data-in-azure-blob-storage?view=azuresql-db&preserve-view=true#accessing-data-in-a-csv-file-referencing-an-azure-blob-storage-location).
          
          Simple or bulk logged recovery models aren't supported in Hyperscale. Full recovery model is required to provide high availability and point-in-time recovery. However, Hyperscale log architecture provides better data ingest rate compared to other Azure SQL Database service tiers.
          
      - question: |
          Does Hyperscale allow provisioning multiple nodes for parallel ingesting of large amounts of data?
        answer: |
          No. Hyperscale is a symmetric multi-processing (SMP) architecture and not a massively parallel processing (MPP) or a multi-master architecture. You can create multiple replicas to scale out read-only workloads.

      - question: |
          Does Hyperscale support migration from other data sources such as Amazon Aurora, MySQL, PostgreSQL, Oracle, DB2, and other database platforms?
        answer: |
          Yes. [Azure Database Migration Service](/azure/dms/dms-overview) supports many migration scenarios.

      - question: |
          When I convert a database to Hyperscale, when does Hyperscale billing begin?
        answer: |
          Hyperscale billing after a conversion begins only after the cutover is complete.

      - question: |
          When I convert to Hyperscale, can I control the disruption to my database?
        answer: | 
          Yes. When you start the conversion, you have the option to specify the nature of the cutover. It can be automatic, as soon as it's ready, or manually initiated when you're ready. For more information, see [Convert a database to Hyperscale](convert-to-hyperscale.md). You can manually initiate the cutover via the Azure portal, PowerShell, Azure CLI, or T-SQL. You'll only experience a short period of downtime, generally less than a minute, during the final cutover to Hyperscale.

  - name: Business continuity and disaster recovery questions
    questions:
      - question: |
          What SLAs are provided for a Hyperscale database?
        answer: |
          See [SLA for Azure SQL Database](https://azure.microsoft.com/support/legal/sla/azure-sql-database). We recommend adding HA secondary replicas for critical workloads. This provides faster failover, and reduces potential performance impact immediately after failover.
          
      - question: |
          Are the database backups managed for me by Azure SQL Database?
        answer: |
          Yes.

      - question: |
          Does Hyperscale support Availability Zones?
        answer: |
          Yes, Hyperscale supports [zone redundant configuration](high-availability-sla-local-zone-redundancy.md#hyperscale-service-tier-zone-redundant-availability). At least one HA secondary replica and the use of zone-redundant or geo-zone-redundant storage is required for enabling the zone redundant configuration for Hyperscale.

      - question: |
          Does Hyperscale support elastic pools?
        answer: |
          Yes. For more information, see [Hyperscale elastic pools](hyperscale-elastic-pool-overview.md) and [Blog: Hyperscale Elastic Pools are now generally available](https://aka.ms/hsep-ga).

      - question: |
          How often are database backups taken?
        answer: |
          There are no traditional full, differential, and transaction log backups for Hyperscale databases. Instead, there are regular storage snapshots of data files, with a separate snapshot cadence for each file. The generated transaction log is retained as-is for the configured retention period. At restore time, relevant transaction log records are applied to restored storage snapshots. Regardless of snapshot cadence, this results in a transactionally consistent database as of the specified point in time within the retention period, without any data loss. In effect, database backup in Hyperscale is continuous.

      - question: |
          Does Hyperscale support point-in-time restore?
        answer: |
          Yes.

      - question: |
          What is the Recovery Point Objective (RPO)/Recovery Time Objective (RTO) for database restore in Hyperscale?
        answer: |
          The RPO for point-in-time restore is 0 min. Most point-in-time restore operations complete within 60 minutes regardless of database size. Restore time can be longer for larger databases, and if the database experienced significant write activity before and up to the restore point in time. Issuing a restore after a recent change of [storage redundancy](hyperscale-automated-backups-overview.md#data-and-backup-storage-redundancy) might result in longer restore times because the restore can be a size-of-data operation in that case, and the restore time might be proportional to the database size.

      - question: |
          Does database backup affect compute performance on my primary or secondary replicas?
        answer: |
          No. Backups are managed by the storage subsystem, and use storage snapshots. They do not impact user workloads.

      - question: |
          Can I perform geo-restore with a Hyperscale database?
        answer: |
          Yes. Geo-restore is fully supported if geo-redundant or geo-zone-redundant storage is used. Geo-redundant storage is the default for new databases. Unlike point-in-time restore, geo-restore requires a size-of-data operation. Data files are copied in parallel, so the duration of this operation depends primarily on the size of the largest file in the database, rather than on total database size. Geo-restore time is significantly shorter if the database is restored in the Azure region that is [paired](/azure/reliability/cross-region-replication-azure) with the region of the source database. For more information, see [Geo-restore for Azure SQL Database](recovery-using-backups.md#geo-restore).
          
      - question: |
          Can I set up geo-replication or use failover groups with a Hyperscale database?
        answer: |
          Yes. [Geo-replication](active-geo-replication-overview.md) and [failover groups](failover-group-sql-db.md) can be set up for Hyperscale databases.

      - question: |
          Can I take a Hyperscale database backup and restore it to my on-premises server, or on SQL Server in a VM?
        answer: |
          No. The storage format for Hyperscale databases is different from any released version of SQL Server, and you don't control backups or have access to them. To take your data out of a Hyperscale database, you can extract data using any data movement technologies such as Azure Data Factory, Azure Databricks, SSIS, etc.

      - question: |
          Will I be charged for backup storage costs in Hyperscale?
        answer: |
           Yes. Effective May 4, 2022, backups for all new databases are charged based on the backup storage consumed and selected storage redundancy at rates captured in [Azure SQL Database pricing page](https://azure.microsoft.com/pricing/details/sql-database/single/). For Hyperscale databases created before May 4, 2022, backups will be charged only if backup retention is set to be greater than seven days. To learn more, see [Hyperscale backups and storage redundancy](hyperscale-automated-backups-overview.md#data-and-backup-storage-redundancy).

      - question: |
          How can I measure backup storage size in my Hyperscale database?
        answer: |
          For details on how to measure backup storage size, see [Automated Backups](hyperscale-automated-backups-overview.md#data-and-backup-storage-redundancy).

      - question: |
          How do I know what my backup bill will be?
        answer: |
          To determine your backup storage bill, backup storage size is calculated periodically, and multiplied by the backup storage rate and the number of hours since the last calculation. To estimate your backup bill for a time period, multiply the billable backup storage size for every hour of the period by the backup storage rate, and add up all hourly amounts. To query relevant Azure Monitor metrics for multiple hourly intervals programmatically, use Azure Monitor [REST API](/azure/azure-monitor/essentials/rest-api-walkthrough). Backup billing in the [serverless compute tier](serverless-tier-overview.md) is the same as in the provisioned compute tier.

      - question: |
          How will my workload influence my backup storage costs?
        answer: |
          Backup costs are higher for workloads that add, modify, or delete large volumes of data in the database. Conversely, workloads that are mostly read-only might have smaller backup costs.

      - question: |
          How can I minimize backup storage costs?
        answer: |
          For details on how to minimize the backup storage costs, see [Automated Backups](hyperscale-automated-backups-overview.md#reduce-backup-storage-consumption).

      - question: |
          Can I geo-restore my Hyperscale database to another service tier, or vice-versa?
        answer: |
          Currently, non-Hyperscale service tiers (Basic/Standard/Premium/General Purpose/Business Critical) backups can't be geo-restored into a Hyperscale service tier and vice-versa. To convert a non-Hyperscale database to a Hyperscale database, change the service tier after a restore.

  - name: Performance questions
    questions:
      - question: |
          How much write throughput can I push in a Hyperscale database?
        answer: |
          Transaction log throughput limit is 100 MiB/s for any Hyperscale compute size. The ability to achieve this rate depends on multiple factors, including but not limited to workload type, client configuration and performance, and having sufficient compute capacity on the primary compute replica to produce log records at this rate. Ingestion or log generation rate is 150 MiB/s per database for premium-series and premium-series memory optimized hardware of Azure SQL Database Hyperscale. For standard-series hardware, the maximum log rate is 100 MiB/s per database. For elastic pools, the maximum log rate is 150 MiB/s per pool for premium-series and premium-series memory optimized hardware, and 125 MiB/s per pool for other hardware.

      - question: |
          How many IOPS do I get on the largest compute?
        answer: |
          IOPS and IO latency vary depending on the workload patterns. If the data being accessed is cached in local SSD storage on the compute replica, you'll see similar IO performance as in Business Critical or Premium service tiers.

      - question: |
          Does my throughput get affected by backups?
        answer: |
          No. Compute is decoupled from the storage layer. This eliminates the performance impact of backup.

      - question: |
          Does my throughput get affected as I provision additional compute replicas?
        answer: |
          Because the storage is shared and there is no direct physical replication happening between primary and secondary compute replicas, the throughput on the primary replica isn't directly affected by adding secondary replicas. However, the log rate for continuous and aggressive write workloads might be limited on the primary to allow log apply on secondary replicas and page servers to catch up. This avoids poor read performance on secondary replicas and long recovery after failover to an HA secondary replica.

      - question: |
          Is Hyperscale well suited for resource-intensive, long-running queries, and transactions?
        answer: |
          Yes. However, just like in other Azure SQL databases, connections might be terminated by very infrequent transient errors, which can abort long-running queries and roll back transactions. One cause of transient errors is when the system quickly shifts the database to a different compute node to ensure continued compute and storage resource availability, or to perform planned maintenance. Most of these reconfiguration events finish in less than 10 seconds. Applications that connect to your database should be built to expect and tolerate these infrequent transient errors by implementing retry logic. Additionally, consider configuring a [maintenance window](maintenance-window.md) that matches your workload schedule to avoid transient errors due to planned maintenance.

      - question: |
          How do I diagnose and troubleshoot performance problems in a Hyperscale database?
        answer: |
          For most performance problems, particularly those not rooted in storage performance, common MSSQL diagnostic and troubleshooting steps apply. For Hyperscale-specific storage diagnostics, see [SQL Hyperscale performance troubleshooting diagnostics](hyperscale-performance-diagnostics.md).
      
      - question: |
          How does the maximum memory limit in serverless compare to provisioned compute?
        answer:  | 
          The maximum amount of memory that a serverless database can scale up is 3 GB/vCore times the maximum number of vCores configured as compared to more than 5 GB/vCore times the same number of vCores in provisioned compute. Review [serverless Hyperscale resource limits](resource-limits-vcore-single-databases.md#hyperscale---serverless-compute---standard-series-gen5) for details.

      - question: |
          How does continuous priming benefit customers?
        answer: |
          Continuous priming helps maintain higher RBPEX (Resilient Buffer Pool Extension) utilization, leading to better performance. It ensures the secondary database is always ready to take over without delay, improving failover times and overall system reliability.

      - question: |
          What compute tiers support continuous priming?
        answer: |
          Continuous priming is available on the provisioned Hyperscale compute tier premium-series hardware and memory-optimized premium series hardware. Continuous priming is not currently available for Hyperscale serverless compute tier.

      - question: | 
          Does continuous priming benefit named replicas?
        answer: |
          Named replicas do not benefit from continuous priming.

  - name: Scalability questions
    questions:
      - question: |
          How long does it take to scale a compute replica up or down?
        answer: |
          Scaling up or down in the provisioned compute tier typically takes up to 2 minutes, regardless of data size. In the serverless compute tier, where compute is automatically scaled based on workload demand, the scaling time is typically subsecond, but can occasionally take as long as when scaling provisioned compute.

      - question: |
          Is my database offline while the scaling up/down operation is in progress?
        answer: |
          No. A database remains online during scale-up or scale-down operations.

      - question: |
          Should I expect a connection drop when the scaling operations are in progress?
        answer: |
          Scaling provisioned compute up or down results in connections being dropped when a failover happens at the end of the scaling operation. In serverless compute, automatic scaling typically does not result in dropping a connection, but it can occur occasionally. Adding or removing secondary replicas does not result in connection drops on the primary.

      - question: |
          Is the scaling up and down of compute replicas automatic or end-user triggered operation?
        answer: |
          Scaling in provisioned compute is performed by the end user. Automatic scaling in serverless compute is performed by the service.

      - question: |
          Does the size of my tempdb database and compute SSD cache also grow as the compute is scaled up?
        answer: |
          Yes. The `tempdb` database and [compute SSD cache](service-tier-hyperscale.md#distributed-functions-architecture) size on compute nodes scale up automatically as the number of cores is increased. For details, see [Hyperscale storage and compute sizes](resource-limits-vcore-single-databases.md#hyperscale---provisioned-compute---gen5).
          
      - question: |
          Can I provision multiple primary compute replicas, such as a multi-master system, where multiple primary compute heads can drive a higher level of concurrency?
        answer: |
          No. Only the primary compute replica accepts read/write requests. Secondary compute replicas only accept read-only requests.

  - name: Read scale-out questions
    questions:
      - question: |
          What kinds of secondary (read scale-out) replicas are available in Hyperscale?
        answer: |
          Hyperscale supports High Availability (HA) replicas, named replicas, and geo-replicas. See [Hyperscale secondary replicas](service-tier-hyperscale-replicas.md) for details.

      - question: |
          How many HA secondary replicas can I provision?
        answer: |
          Between 0 and 4. If you want to adjust the number of replicas, you can do so using [Azure portal](https://portal.azure.com) or [REST API](/rest/api/sql/databases/create-or-update).
          
      - question: |
          How do I connect to an HA secondary replica?
        answer: |
          You can connect to these additional read-only compute replicas by setting the `ApplicationIntent` property in your connection string to `ReadOnly`. Any connections marked with `ReadOnly` are automatically routed to one of the HA secondary replicas, if present. For details, see [Use read-only replicas to offload read-only query workloads](read-scale-out.md).
          
      - question: |
          How do I validate if I have successfully connected to a secondary compute replica using SQL Server Management Studio (SSMS) or other client tools?
        answer: |
          You can execute the following T-SQL query: `SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability')`. The result is `READ_ONLY` if you are connected to a read-only secondary replica, and `READ_WRITE` if you are connected to the primary replica. The database context must be set to the name of your database, not to the `master` database.
          
      - question: |
          Can I create a dedicated endpoint for an HA secondary replica?
        answer: |
          No. You can only connect to HA secondary replicas by specifying `ApplicationIntent=ReadOnly`. However, you can use dedicated endpoints for [named replicas](service-tier-hyperscale-replicas.md#named-replica). 

      - question: |
          Does the system do intelligent load balancing of the read-only workload on HA secondary replicas?
        answer: |
          No. A new connection with read-only intent is redirected to an arbitrary HA secondary replica.

      - question: |
          Can I scale up/down HA secondary replicas independently of the primary replica?
        answer: |
          Not in the provisioned compute tier. HA secondary replicas are used as high availability failover targets, so they need to have the same configuration as the primary to provide expected performance after failover. In serverless, the compute is scaled automatically for each HA replica based on its individual workload demand. Each HA secondary can still autoscale to the configured max cores to accommodate its post-failover role. [Named replicas](service-tier-hyperscale-replicas.md#named-replica) provide the ability to scale each named replica independently.

      - question: |
          Do I get different tempdb sizing for my primary compute and my HA secondary replicas?
        answer: |
          No. Your `tempdb` database is configured based on the provisioned compute size; your HA secondary replicas are the same size, including `tempdb`, as the primary compute. On [named replicas](service-tier-hyperscale-replicas.md#named-replica), `tempdb` is sized according to the compute size of the replica, thus it can be smaller or larger than `tempdb` on the primary.

      - question: |
          Can I add indexes and views on my secondary compute replicas?
        answer: |
          No. Hyperscale database compute replicas share storage, meaning that all compute replicas see the same tables, indexes, and other database objects. If you want additional indexes optimized for reads on secondary, you must add them on the primary. You can still create temporary tables (table names prefixed with # or ##) on each secondary replica to store temporary data in the `tempdb` database. Temporary tables are read-write.

      - question: |
          How much delay is there between the primary and secondary compute replicas?
        answer: |
          Data latency from the time a transaction is committed on the primary to the time it is readable on a secondary depends on the current log generation rate, transaction size, load on the replica, and other factors. Typical data latency for small transactions is in tens of milliseconds, however there's no upper bound on data latency. Data on a given secondary replica is always transactionally consistent, thus larger transactions take longer to propagate. At a given point in time data latency and database state might be different for different secondary replicas. Workloads that need to read committed data immediately should run on the primary replica.

      - question: |
          Can a named replica be used as a failover target?
        answer: |
          No, named replicas cannot be used as failover targets for the primary replica. Add HA replicas for the primary replica for that purpose.

      - question: |
          How can I distribute a read-only workload across my named replicas?
        answer: |
          Since every named replica can have a different service level objective and thus be used for different use cases, there's no built-in way to direct read-only traffic sent to the primary to a set of named replicas. For example, you can have eight named replicas, and you might want to direct OLTP workload only to named replicas 1 to 4, while Power BI analytical workloads use named replicas 5 and 6, and the data science workload uses replicas 7 and 8. Depending on which tool or programming language you use, strategies to distribute such workload could vary. For an example of creating a workload routing solution to allow a REST backend to scale out, review the [OLTP scale-out sample](https://github.com/Azure-Samples/azure-sql-db-named-replica-oltp-scaleout).

      - question: |
          Can a named replica be in a region different from the region of the primary replica?
        answer: |
          No, as named replicas use the same page servers of the primary replica, they must be in the same region. However, if you created a geo-replica for the primary replica in a different region, you can create named replicas for the geo-replica.

      - question: |
          Can a named replica impact availability or performance of the primary replica?
        answer: |
          A named replica cannot impact the availability of the primary replica. Named replicas, under normal circumstances, are unlikely to impact the primary's performance, but it can happen if there are intensive workloads running. Just like an HA replica, a named replica is kept in sync with the primary via the transaction log service. If a named replica, for any reason, is not able to consume transaction log fast enough, it starts asking the primary replica to reduce its log generation rate, so that it can catch up. While this behavior doesn't impact the primary's availability, it can impact performance of write workloads on the primary. To avoid this situation, make sure that your named replicas have enough resource headroom - mainly CPU - to process transaction log without delay. For example, if the primary is processing numerous data changes, it is recommended to have named replicas with at least the same compute size as the primary to avoid saturating CPU on the replicas and forcing the primary to slow down.

      - question: |
          What happens to named replicas if the primary replica is unavailable, for example, because of planned maintenance?
        answer: |
          Named replicas are still available for read-only access, as usual.

      - question: |
          How can I improve availability of named replicas?
        answer: |
          By default, named replicas don't have any HA replicas of their own. A failover of a named replica requires creating a new replica first, which typically takes about 1-2 minutes. However, named replicas can also benefit from higher availability and shorter failovers provided by HA replicas. You can add HA replicas for a named replica in the Azure portal, or using the parameter `ha-replicas` with [AZ CLI](/cli/azure/sql/db/replica#az_sql_db_replica_create), or the parameter `HighAvailabilityReplicaCount` with [PowerShell](/powershell/module/az.sql/set-azsqldatabase), or the `highAvailabilityReplicaCount` property with [REST API](/rest/api/sql/databases/create-or-update). The number of HA replicas can be set during the creation of a named replica and can be changed anytime after the named replica has been created. Pricing of HA replicas for named replicas is the same of HA replicas for primary replicas.
    
      - question: |
          If Always Encrypted is enabled on Hyperscale database, will rotating the Column Master Key (CMK) on the primary database also update the key on secondary replicas?

        answer: |
          Yes. The [Column Master Key](/sql/t-sql/statements/create-column-master-key-transact-sql?view=azuresqldb-current&preserve-view=true) is stored in the user database and can be validated by executing the query `SELECT * FROM sys.column_master_keys`. Named replicas and high availability secondary replicas read data from the same page servers/storage layer as the primary Hyperscale database. Both types of replicas are synchronized with the primary Hyperscale database via the log service. A key change is considered a transaction and is automatically replicated to all secondary replicas.

      - question: |
          How do I query information about Hyperscale database secondary replicas?

        answer: |

          You can connect to the primary replica and determine its replica ID and the details of other secondary replicas using the `sys.dm_hs_database_replicas` DMF. For more information, see [sys.dm_hs_database_replicas](/sql/relational-databases/system-functions/sys-dm-hs-database-replicas). The following example returns a row for each replica of a Hyperscale database named `Contosodb`. 

          ```sql
          SELECT replica_role_desc, replica_server_name, replica_id
          FROM sys.dm_hs_database_replicas(DB_ID(N'Contosodb'));
          ```

          You can also connect to a secondary replica to determine its replica ID and other details. The following sample query of [sys.dm_database_replica_states](/sql/relational-databases/system-dynamic-management-views/sys-dm-database-replica-states-azure-sql-database) shows the details for the current replica context:

          ```sql
            SELECT replica_id,
                   DB_NAME() AS named_replica_database_name,
                   synchronization_state_desc,
                   log_send_queue_size / 1024.0 / 1024.0 AS log_send_queue_size_gb,
                   last_sent_time,
                   last_received_time,
                   last_commit_time,
                   redo_queue_size / 1024.0 / 1024.0 AS redo_queue_size_gb,
                   redo_rate,
                   secondary_lag_seconds
            FROM sys.dm_database_replica_states
            WHERE is_local = 1
                  AND
                  replica_id = DATABASEPROPERTYEX(DB_NAME(), 'ReplicaID');
          ```

additionalContent: |

  ## Related content
  
  For more information about the Hyperscale service tier, see [Hyperscale service tier](service-tier-hyperscale.md).