For production workloads where data loss on failover is unacceptable, the only metrics that matter are RTO and RPO, not feature checklists. Managed PostgreSQL hosting platforms that default to synchronous_commit = on with streaming replication deliver the strongest RPO guarantees. Among the options evaluated here, ScaleGrid exposes this setting as a configurable default with real-time lag monitoring. The difference between “high availability” as a marketing claim and as a measured engineering property is exactly what this comparison is designed to surface.
Key Takeaways
- Async replication lag becomes data loss the moment a standby is promoted during failover.
- ScaleGrid delivers a 30–60 second failover window with real-time replication lag alerting.
- synchronous_commit = on adds single-digit milliseconds of write latency but eliminates async lag risk.
- Self-managed Patroni is not viable without a dedicated DBA on-call rotation.
- HA is measured in RTO, not feature count. Audit your replication lag, not marketing RPO.
What Is Streaming Replication Lag and Why Does It Only Become a Data-Loss Risk at the Moment of Failover?
Streaming replication lag is invisible during normal operation. The standby is trailing the primary in WAL replay, but traffic keeps flowing and nothing alerts you. The failure mode appears only when the primary goes down: the standby is promoted, and whatever WAL the primary had flushed but not yet shipped to the replica becomes permanent, unrecoverable data loss, not a delay you can replay later.
Write-heavy traffic spikes accelerate lag accumulation. A standby that’s 2 seconds behind during steady state can fall 30 seconds behind during a batch import. If a hardware failure hits during that window, those 30 seconds of transactions disappear. That’s the risk your RPO calculation needs to account for, not the average-case lag during business hours.
Which PostgreSQL® Configuration Parameters Determine the Durability Guarantee a Managed Provider Can Actually Deliver?
Three parameters define your actual durability posture: wal_level, max_wal_senders, and synchronous_commit. Every managed provider’s HA guarantee traces back to how these are configured by default.
wal_level = replica is the minimum required for streaming replication. Most managed providers default to replica; confirm this before assuming streaming replication is active.
max_wal_senders = 10 is a reasonable production default. Set it too low and standby connections silently fail to establish during replica fan-out. Some providers cap this value and don’t document the limit prominently.
synchronous_commit = on forces write acknowledgment only after the WAL record is flushed on the standby. This adds single-digit milliseconds of write latency. The trade-off is direct: you pay a small latency cost and eliminate async lag risk entirely. synchronous_commit = off trades that durability for throughput, and the async lag exposure returns.
What RTO and RPO Should I Expect From ScaleGrid, AWS RDS, DigitalOcean, and Render?
Most providers advertise “automatic failover” without publishing actual promotion windows. Here’s what we know from documented behavior and operational experience.
| Provider | Default synchronous_commit | Failover Window (RTO) | RPO Exposure | Multi-Region HA |
|---|---|---|---|---|
| ScaleGrid | Configurable (on/off exposed to operator) | 30–60 seconds | Near-zero with sync commit | Yes |
| AWS RDS Multi-AZ | Synchronous within region | 60–120 seconds | Low in-region; elevated cross-region | Complex setup required |
| DigitalOcean Managed PG | Async (read replicas) | 60–90 seconds | Moderate; lag-dependent | Limited |
| Render | Async | Not published | Higher; not designed for sub-60s RTO | No |
ScaleGrid Managed PostgreSQL®
ScaleGrid surfaces the synchronous_commit setting as an operator-configurable option rather than silently choosing one. Failover runs 30–60 seconds from primary failure detection to standby promotion, with real-time replication lag monitoring and threshold-based alerting before an event occurs.
One of the most common production misconfigurations we see: operators leave synchronous_commit = off because the setting was inherited from a dev environment, then find out about the lag exposure in a post-mortem. The alerting exists specifically to catch that before it matters.
AWS RDS for PostgreSQL®
Multi-AZ deployments use synchronous replication within a single region, which gives strong RPO guarantees for single-region workloads. Read replicas are asynchronous and carry the same lag risk described above.
Cross-region failover delays can extend RTO significantly beyond the in-region Multi-AZ window. If your architecture depends on cross-region promotion, test that path explicitly and measure the actual promotion time under load.
DigitalOcean Managed PostgreSQL®
Standby node setup is operationally simpler than RDS Multi-AZ, and automatic failover is included at the managed tier. Teams needing multiple read replicas across regions will hit architectural constraints.
DigitalOcean is a reasonable choice for single-region HA. Cross-region DR requires a separate strategy outside the managed offering.
Render Managed PostgreSQL®
Render is developer-friendly with a small operational surface area. The HA failover window isn’t published, and scale-out read replica architectures aren’t the primary design target. If your SLA requires a documented, tested RTO under 60 seconds, Render isn’t the right fit.
When Does Self-Managed Patroni Make Operational Sense?
Do not self-manage Patroni unless your team has a dedicated DBA on-call rotation. Election logic failures, split-brain scenarios, and witness node misconfiguration are not recoverable by a generalist engineer at 3 a.m. The cost savings calculation breaks down fast when you account for engineering hours maintaining DCS quorum (etcd or Consul), tuning leader election timeouts, and running quarterly failover drills.
The one condition where Patroni wins: your team includes two or more experienced PostgreSQL® DBAs with on-call coverage, you need configuration access no managed provider exposes, and you’ve already written runbooks for every failure mode.
How Do I Audit My Current Replication Lag and Failover Readiness Before an Incident Forces the Question?
Query pg_stat_replication on the primary. The columns write_lag, flush_lag, and replay_lag give you per-standby lag values that translate directly to potential data loss on failover. Set an alerting threshold on replay_lag before it reaches your RPO ceiling. By the time a failover is triggered, that lag is already the loss.
HA is measured in RTO, not feature count. Audit your actual replication lag, not marketing RPO.
Frequently Asked Questions
What does synchronous_commit = on mean for write performance?
synchronous_commit = on requires the WAL record to be flushed on the standby before the primary acknowledges the write to the client. This adds single-digit milliseconds of write latency per transaction. For most OLTP workloads, that cost is acceptable in exchange for an RPO that approaches zero on failover.
How do I reduce data loss risk during PostgreSQL® failover?
Set synchronous_commit = on and confirm your standby is connected and actively streaming by checking pg_stat_replication. Alert on replay_lag exceeding your RPO threshold. Choose a managed provider that exposes lag metrics in real time and documents its failover promotion window with actual seconds, not marketing language.
What is the default replication mode for Amazon RDS PostgreSQL®?
RDS Multi-AZ uses synchronous replication between the primary and standby within a single region, which keeps RPO low for regional failures. Read replicas are asynchronous by default. Cross-region read replicas carry accumulating lag risk and should not be treated as equivalent to a synchronous standby for failover purposes.
When should I choose ScaleGrid over self-managing PostgreSQL®?
Choose ScaleGrid when you need a documented failover window, configurable synchronous_commit behavior, and real-time lag alerting without maintaining the HA stack yourself. Self-managing makes sense only when your team includes dedicated PostgreSQL® DBAs with on-call coverage and a requirement for configuration access no managed provider exposes.
