Azure Database for PostgreSQL Flexible Server
Zone-redundant HA is synchronous with zero data loss and automatic failover in 60-120 seconds — but same-zone HA, a separately-named and identically-priced option, offers the same automatic failover mechanics while never leaving the zone, so it doesn't survive a zone outage at all. Cross-region continuity is read replicas only: asynchronous, with unbounded replication lag, and Microsoft is explicit that promotion is always customer-triggered, even during a declared regional outage. There is no auto-failover-group equivalent for PostgreSQL Flexible Server.
No high availability (default)
A single server with no standby. Storage is durable and separate from compute (three locally redundant copies), and Azure automatically provisions a new VM and remounts storage if the server crashes — but there's no synchronous replica, so anything beyond a simple node crash requires a point-in-time restore from backup.
- Replication
- None
- RPO
- 0 for a simple node/VM crash, since storage persists independently and is automatically remounted; for a zone outage there's no standby to fail over to, so recovery means point-in-time restore, and Microsoft doesn't publish a specific recovery-point granularity for that path
- RTO
- Not published for automatic node relocation; for a zone outage, restore time depends on backup size and transaction log volume with no fixed figure given
- Failover trigger
- Manual (customer-triggered)
- Relative cost
- No extra cost
Baseline — compute and storage for a single server, no standby to pay for.
This is what you get without explicitly enabling one of the two HA modes below. Both HA modes are billed as a full second server, so the jump from this tier isn't cheap — but it's the only tier with no automatic zone protection at all.
Shows Unknown at every tier — there's no fixed RPO/RTO for this option; it depends entirely on an architecture you'd have to design and build.
Zone-redundant HA
A standby server is placed in a different Availability Zone from the primary and kept in sync via synchronous streaming replication (plus a WAL-replica server in a third zone to maintain commit quorum). On a detected primary failure, Azure automatically promotes the standby — no customer action required.
- Replication
- Synchronous
- RPO
- 0 — Microsoft states zero data loss for both planned and unplanned zone-redundant failover
- RTO
- 60-120 seconds for automatic failover per Microsoft's documented range — but Microsoft's own docs note the failover process 'might take longer than 120 seconds' if the standby has a large recovery backlog to replay before promotion
- Failover trigger
- Automatic
- Relative cost
- High cost premium
The standby server is billed at the same rate as the primary — effectively doubles compute and storage cost. Same-zone HA costs identically, so there's no price incentive to pick the weaker option.
Azure also sells 'same-zone (zonal) HA' — architecturally identical automatic failover, same 60-120s range, same price — but the standby stays in the primary's zone. It protects node failure only; if that shared zone fails, both primary and standby go down together and you're back to a point-in-time restore (see gotchas). Same-zone HA carries a 99.95% SLA vs. 99.99% here, and exists mainly for regions without zone-redundant support or when zonal capacity is temporarily unavailable.
Cross-region read replica + virtual endpoint (customer-managed promotion)
Up to five read replicas, optionally in a different Azure region, kept in sync via PostgreSQL's native asynchronous physical replication. A virtual endpoint gives you a stable read-write hostname that gets redirected automatically once you promote a replica — but Azure never initiates that promotion itself, even during a declared regional outage.
- Replication
- Asynchronous
- RPO
- Not guaranteed. Microsoft's guidance: lag 'typically ranges from a few seconds to minutes,' and 'in some heavy workload or high-latency scenarios, this delay could extend to hours.' A forced promotion during an outage permanently loses any unreplicated data.
- RTO
- The forced-promotion step itself 'typically completes within 1-3 minutes' once triggered — but Microsoft is explicit that you're responsible for detecting the regional outage and triggering promotion; there's no published figure for that detection-and-decision time, so total time-to-recovery isn't bounded
- Failover trigger
- Manual (customer-triggered)
- Relative cost
- High cost premium
A read replica is a full separate server — its own compute and storage billed continuously, plus cross-region data-transfer charges for the ongoing replication stream.
There is no auto-failover-group equivalent for PostgreSQL Flexible Server (Azure SQL Database has one; Postgres doesn't). Per Microsoft's reliability docs: 'You're responsible for triggering promotion. Azure doesn't promote read replicas automatically, even if there's a region failure.' A promoted replica also loses HA configuration — you must re-enable zone-redundant or same-zone HA on it manually after promotion.
Shows Unknown at every tier — there's no fixed RPO/RTO for this option; it depends entirely on an architecture you'd have to design and build.
Gotchas
"Same-zone HA" and "zone-redundant HA" cost the same but protect against different things
Both HA modes fail over automatically with zero data loss in the same 60-120 second range, and both bill the standby at the primary's full rate — so there's no cost signal distinguishing them. The difference is entirely about placement: zone-redundant puts the standby in a separate Availability Zone and survives a zone outage; same-zone HA puts the standby in the same zone as the primary, so a zone failure takes both servers down together, and recovery falls back to a point-in-time restore with no fixed RTO/RPO. Same-zone HA exists mainly as a fallback for regions or moments when zone-redundant capacity isn't available — verify which one is actually configured, since the naming alone doesn't make the distinction obvious.
Cross-region promotion is never automatic — Microsoft says so explicitly
Even during a full regional outage, Azure will not promote a read replica on your behalf. Microsoft's reliability documentation states: "You're responsible for triggering promotion. Azure doesn't promote read replicas automatically, even if there's a region failure." The 1-3 minute promotion time only starts once you've detected the outage and issued the command — there's no SLA or published figure covering detection-to-decision time, so real-world RTO for cross-region recovery is whatever your team's operational readiness makes it.
Replication lag to read replicas is unbounded, not just 'asynchronous'
Microsoft's own guidance is that lag 'typically ranges from a few seconds to minutes,' but under heavy write load or high network latency it 'could extend to hours' — and a forced promotion during an outage permanently loses whatever hadn't replicated at that moment. Don't budget a specific RPO for cross-region read replicas without actively monitoring the replication-lag metric; there is no bound Microsoft will commit to.
There's no PostgreSQL equivalent of Azure SQL's auto-failover groups
If you're used to Azure SQL Database's failover groups (even the discouraged 'automatic' policy), don't assume PostgreSQL Flexible Server has anything comparable. The only cross-region primitive is read replicas with manual/forced promotion — there is no Microsoft-managed automatic regional failover option at all, not even a slow or best-effort one.
A promoted replica comes up with no HA and needs to be reconfigured
Read replicas can't have high availability enabled while they're replicas, and a replica promoted to primary doesn't inherit or retain HA configuration — you (or your automation) must enable same-zone or zone-redundant HA on it after promotion. Until you do, the newly promoted primary is a single point of failure again.
Zone redundancy must be chosen explicitly and per-server; you can't change zones later without recreating
Zone-redundant vs. same-zone HA is a deployment-time (or reconfiguration-time) choice, and once a server is created you can't change which specific availability zone hosts the primary or standby — that requires recreating the server. Confirm the HA mode and zone placement at provisioning time rather than assuming it can be adjusted later without downtime.