TL;DR — Multi-region Postgres on Hetzner is feasible and operationally light if you use async streaming replication, treat failover as a deliberate decision rather than automatic, and invest in observability up front. The cost is dramatically lower than RDS multi-AZ; the responsibility is higher.
RDS multi-AZ buys you “click a checkbox” multi-region with a 5-10x cost markup. On Hetzner you set it up yourself, pay 1/10 the price, and own the responsibility. For mid-scale SaaS, the trade-off is usually worth it.
The topology
- Primary in one region, sized for write workload
- Async streaming replicas in the same region (read scaling) and a different region (DR)
- WAL archive shipped to S3-compatible object storage for point-in-time recovery
- PgBouncer in front of every Postgres for connection pooling
- HAProxy routing reads to replicas, writes to primary
Why async streaming, not synchronous
Synchronous replication is appealing because it sounds safer. In practice it ties write latency to replica responsiveness. One slow replica blocks every write. Async is what we recommend unless you have a specific durability requirement that justifies the trade-off.
Failover as a deliberate choice
Automatic failover tools (Patroni, repmgr) work but introduce split-brain risk under partition. Our default: manual failover, runbook-driven, alarms-first. The replica is hot, the procedure is rehearsed, the engineer is in the loop. This is operationally lighter than it sounds.
Observability that matters
- Replication lag per replica, alarm at 30 seconds
- WAL receiver process uptime per replica
- Backup success and last successful PITR test
- Connection pool saturation at PgBouncer
- Disk space with multi-day projection, not just current
What this costs vs RDS
| Setup | AWS RDS | Hetzner self-managed |
|---|---|---|
| Primary + 1 same-region replica | ~$600/mo | ~$120/mo |
| Primary + 2 replicas + DR replica | ~$1,400/mo | ~$250/mo |
| Backup storage (1 TB) | ~$95/mo | ~$15/mo |
Frequently asked questions
Multi-region for read scaling or for DR?
Both, with different setups. Read scaling: async replicas in the same region or nearby. DR: async replicas in a different region or different provider entirely. The replication is the same; the topology and the failover policy differ.
When does multi-region not pay back?
When your read traffic does not exceed what one Postgres can serve, or when your RTO/RPO targets allow simpler backup-based recovery. Most early-stage SaaS does not need multi-region.
Working on something similar?
T-Square architects, builds and operates production systems for learning, AI and custom software products. Talk to a senior engineer for a second opinion.