Azure SQL Database
Zone-redundant HA (Premium/Business Critical/Hyperscale) is synchronous and near-instant. Cross-region continuity via auto-failover groups is asynchronous and, per Microsoft's own guidance, should be triggered by you — not left to the 'automatic' policy.
Single database, no zone redundancy
Default deployment in one zone. Built-in platform HA still protects against node failure via remote storage/replica mechanisms depending on tier, but a zone-wide event impacts availability.
- Replication
- Synchronous
- RPO
- 0 for node-level failure; for a real outage requiring restore, bounded by backup log frequency (point-in-time restore)
- RTO
- Restore time scales with database size — typically hours for anything beyond a small database
- Failover trigger
- Manual (customer-triggered)
Zone-redundant configuration (Premium / Business Critical / Hyperscale)
Replicas synchronously spread across Availability Zones with automatic failover.
- Replication
- Synchronous
- RPO
- 0
- RTO
- Well under a minute — typically low seconds for Business Critical
- Failover trigger
- Automatic
Must be explicitly enabled — not on by default even on eligible tiers, and not inherited by geo-secondaries created via failover groups except on Hyperscale.
Auto-failover groups (customer-managed policy, recommended)
Asynchronous replication to a secondary server/region with a stable listener endpoint. Microsoft explicitly recommends the customer-managed failover policy over the Microsoft-managed one.
- Replication
- Asynchronous
- RPO
- Typically ~5 seconds under normal load — not a hard guarantee, and lag can grow under heavy write volume
- RTO
- Seconds once triggered for a clean (no-data-loss) failover — but only after you detect the outage and initiate it
- Failover trigger
- Manual (customer-triggered)
A Microsoft-managed (automatic) policy exists but only triggers during a declared regional outage after a grace period Microsoft won't set below 1 hour — Microsoft's own docs say don't rely on it.
Gotchas
"Automatic" failover groups aren't really automatic — and Microsoft says so
The Microsoft-managed failover policy only fires during a widespread regional outage, requires a minimum 1-hour grace period, and Microsoft's documentation explicitly recommends using customer-managed (manual) failover instead. For anything tighter than roughly an hour, SQL cross-region continuity is an operational capability your team executes, not a platform guarantee.
Forced failover can lose the last few seconds of writes
Because replication to the geo-secondary is asynchronous, a forced failover during an actual outage carries potential data loss for unreplicated transactions — 'no data loss' failover is only possible when the primary is still reachable to finish synchronizing first.
Zone redundancy isn't automatically carried to the DR secondary
Creating a secondary via a failover group does not enable zone redundancy on it by default (Hyperscale is the exception, where it's inherited) — you must turn it on explicitly after creation or your DR region silently has weaker zonal protection than production.