Postgres HA and replication tooling
The High-Availability section of awesome-postgres, all thirteen entries, as catalogued on 2026-08-20. patroni is written up separately from its own documentation; everything else here is recorded at the catalog's word (T3) and has not been checked against its primary source. Read this as a map of the field and a queue of candidates, not as verified fact about any one project.
What the section shows, taken whole, is that "high availability" for Postgres splits into three jobs that different projects solve at different layers.
Failover orchestration — deciding who is primary
| Entry | Catalogued as |
|---|---|
| patroni | HA template with ZooKeeper or etcd. Paged from primary sources |
| Stolon | HA based on Consul/etcd with Kubernetes |
| repmgr | Tool suite for managing replication and failover |
| pg_auto_failover | Extension and service for automated failover |
| PAF | PostgreSQL Automatic Failover via Pacemaker/Corosync |
| autobase | Open-source DBaaS automating deployment of highly available clusters |
| pglookout | Replication monitoring and failover daemon |
| pg-status | Microservice providing HTTP endpoints for master/replica status |
The pattern patroni established holds across the top of this list: none of these implement consensus. They lean on an external store that does — etcd, Consul, ZooKeeper, or Pacemaker's own cluster stack — and reduce failover to lease renewal plus a promotion decision.
Two are worth a primary read later. PAF is the outlier that uses Pacemaker/Corosync, a general Linux cluster manager rather than a DCS, which is a different fencing and quorum story from Patroni's. And pg_auto_failover is from citus-data — the same house whose extension refuses to ship its own HA — which makes its existence a small puzzle worth resolving.
Multi-master — more than one node taking writes
| Entry | Catalogued as |
|---|---|
| BDR | BiDirectional Replication multimaster system |
| Spock | Logical multi-master replication (100% open-source) |
| Slony-I | Master-to-multiple-slaves replication with cascading |
| SkyTools | Replication tools including PgQ and Londiste |
These are built on logical-replication rather than physical streaming, for the structural reason that page records: byte-for-byte block shipping cannot let both ends write. What none of the catalog lines say — and what a primary read would have to answer — is how each handles write conflicts, which is the entire hard part and the single-engine version of the merge-semantics argument between event-sourcing and CRDTs that this spoke already carries.
WAL movement
| Entry | Catalogued as |
|---|---|
| pgrwl | Stream WAL in real-time, container-friendly alternative |
One entry, and it belongs as much to pgbackrest's territory as to this section — the archive path is a shared dependency of both backup and standby provisioning. See write-ahead-logging.
Next candidates
pg_auto_failover (the Citus Data puzzle), Spock or BDR (conflict resolution, which would answer a question three pages here leave open), and PAF (a non-DCS fencing model).
Related
patroni · write-ahead-logging · logical-replication · pgbackrest · citus · consensus · awesome-postgres · operational-databases