Why PITR Restore for Azure SQL Hyperscale Can Take Longer Than Expected

Azure SQL Database Hyperscale is designed to deliver fast, storage‑optimized backup and restore operations. According to Microsoft documentation, most Point‑in‑Time Restore (PITR) operations for Hyperscale should complete within 10 minutes, regardless of database size, because the service uses metadata-based restore techniques rather than copying full data files. However, some real‑world scenarios can lead to unexpectedly long restore times, even when the source database is Hyperscale and even when no obvious configuration changes are made.

This article explains one such scenario, outlines what happened, and provides guidance to avoid similar delays in the future. Expected behavior for hyperscale pitr Hyperscale databases use a unique architecture that separates compute and storage. Backups are taken from storage snapshots and do not require data copying during a typical PITR restore.

From Microsoft Learn: “Most restores complete within minutes, even for large databases.” Ref: This performance expectation applies as long as the Backup Storage Redundancy remains the same between the source DB and the target restore. Instead, the restore took significantly longer. Why the restore took longer Although the source database used Standard_RAGRS, enabling Zone Redundancy at restore time introduced a configuration change that affected the underlying Backup Storage Redundancy (BSR) for the newly restored database..