Azure SQL Hyperscale – Compute/Storage Decoupling and Archive Use Case

Hello Janice Chi
Kindly please review the below information,

1. Can Hyperscale (serverless) truly decouple compute and storage, such that storage is always billed but compute charges drop to near-zero when the database is idle?

• Yes, serverless compute in Hyperscale bills compute per second, and storage is billed separately per hour—so when compute is idle (or paused), you only pay for storage. 
• However, as of now, auto-pausing/resuming support in Hyperscale is not yet available, that feature exists only in the General Purpose serverless tier. So, while the compute vs storage billing is decoupled, your compute doesn't auto-pause today. 
  https://techcommunity.microsoft.com/blog/azuresqlblog/general-availability-serverless-for-hyperscale-in-azure-sql-database/4053589

2. Are there any limitations on separating archive tables into a dedicated Hyperscale database to optimize cost?

• You can absolutely isolate archive tables into their own Hyperscale database. This would let you scale and configure compute bounds (even using serverless) specifically for the archive workload.
• Migration between tiers or adjusting settings (like backup redundancy) may require redeployment. Changing long-term retention or redundancy (LRS/GRS) in Hyperscale isn't possible after provisioning.

3. What is the typical cold-start latency when resuming compute from idle/paused state in Hyperscale serverless?

• Since Hyperscale auto-pause/resume isn’t available yet, this scenario only applies once fully supported.
• In General Purpose serverless, resuming typically takes about a minute or less, during which queries can fail or timeout.  The first query may time out, and subsequent attempts succeed. 
  https://techcommunity.microsoft.com/blog/azuresqlblog/optimize-price-performance-with-compute-auto-scaling-in-azure-sql-database-serve/966149

4. Can we separate hot data and cold data in Hyperscale?

• Yes, technically you can partition workloads:
• Keep “hot” data in provisioned compute (more responsive).
• Spin off cold/archive tables into a Hyperscale database with lower compute tiers—or serverless in the future.
• This enables better resource allocation and cost control.

5.For archive workloads that are queried only occasionally (e.g., auditor reports a few times a month), is Hyperscale more cost-effective than keeping archive data in ADLS + querying via Databricks/Synapse?

• Hyperscale serverless (when active) could make sense for intermittent SQL queries—compute is billed per second, and you avoid always-on compute costs. But without auto-pause today, compute still runs even when idle (unless you manually scale it to minimal provisioned).
• Meanwhile, ADLS + Databricks/Synapse offers a very cost-effective solution for rarely accessed, large-scale data. Storage in ADLS is extremely cheap (especially cold tiers), and compute (like Databricks serverless SQL or Synapse SQL Serverless) can be fired up only when needed.

6.Are there recommended best practices for balancing Hyperscale vs ADLS in long-term healthcare data retention scenarios?

1. Use ADLS (cold or archive-tier) for long-term, infrequently accessed healthcare data. It’s compliant, cost-effective, and scalable.
2. Provision an interactive compute layer:
   • If you need SQL-like access, use Azure Synapse serverless SQL Pools or Databricks SQL endpoints: spin up compute on demand, pay only per query/job.
3. Separate hot vs. cold:
   • Hot data lives in provisioned SQL (Hyperscale or provisioned tier).
   • Cold archive data stays in ADLS.
4. Hybrid for rare real‑time archiving needs:
   • If occasional SQL queries are required against archives, consider loading on-demand subsets into a temporary Hyperscale (or regular SQL) instance for those sessions.