Replica lag trade‑off in Azure SQL Database read‑scale‑out

The goal is to understand how acceptable replica lag should be balanced against reduced primary latency when using Azure SQL Database’s read‑scale‑out feature to offload heavy read workloads.

Constraints include the chosen service tier, the size and type of read‑only secondary, and the latency tolerance of the application consuming the replicated data. The read‑scale‑out feature allows reads to be served from a secondary replica, but the replica lag is workload‑dependent and not guaranteed by a fixed SLA.

Uncertainty arises because replica lag can vary with query mix, data change rate, and network conditions, making it difficult to predict the exact delay that will be incurred for a given concurrent load.

What is the maximum replica lag that can be tolerated for a latency‑sensitive application before read‑scale‑out becomes counter‑productive? How can we quantify the trade‑off between primary latency reduction and secondary replica lag across different service tiers? Are there recommended thresholds or monitoring practices to decide when to switch between primary and secondary reads?