Patroni vs repmgr: PostgreSQL High Availability Tools Compared, with pg_auto_failover, Pgpool-II and CloudNativePG

The short answer

For new self-managed PostgreSQL clusters, choose Patroni; on Kubernetes, choose CloudNativePG or a Patroni-based operator. Patroni elects a primary through a distributed configuration store (etcd, Consul, ZooKeeper or the Kubernetes API), which is the most robust way to prevent two primaries after a network split. It is MIT licensed, actively developed, and released 4.1.5 in August 2026. repmgr is simpler to set up, with no extra store to run, but its failover decisions rest on a daemon per node plus an optional witness. It is still maintained by EnterpriseDB and supports PostgreSQL 13 to 18, yet its last release, 5.5.0, dates from November 2024. If repmgr runs well for you today, there is no emergency. If you are designing something new, start with Patroni.

PostgreSQL HA tools at a glance

How Patroni works

Patroni runs next to PostgreSQL on every node and manages it. The primary holds a leader lock in a distributed configuration store (DCS) and renews it on a loop; if the lock is not renewed within its TTL, 30 seconds by default, the replicas race for it and one is promoted. Because the store itself uses consensus, a node that is cut off cannot keep or win the lock, which is what stops two primaries running at once. Patroni supports etcd, Consul, ZooKeeper and the Kubernetes API as the store; its built-in Raft option has been deprecated since 3.0.

Patroni exposes a REST API on each node. Load balancers such as HAProxy call endpoints like /primary or /replica as health checks, so clients follow the primary without application changes. patronictl handles switchovers, restarts and configuration changes. The cost is the store: you now run and patch etcd, Consul or ZooKeeper as well, and that store often ends up older than the database it protects. Our Patroni support page covers that gap, and Patroni: ZooKeeper to etcd covers moving it.

How repmgr works

repmgr is a set of command-line tools for cloning standbys, registering nodes, switching over and following a new primary, plus repmgrd, a daemon that monitors the cluster and automates failover. There is no external store. When the primary disappears, the standbys decide among themselves whether to promote. To stop a standby in another data centre promoting itself during a network split, repmgr offers a witness server, an ordinary PostgreSQL instance outside the replication cluster placed with the primary, and a primary visibility consensus option that makes standbys check with each other first. repmgr's own documentation notes that the location-based approach does not scale well to complex topologies.

repmgr does not route clients. It records events and can call a script you supply through event_notification_command, which teams use to move a virtual IP, update DNS or reconfigure a proxy. The repmgr package must match the PostgreSQL major version, and all nodes must run the same repmgr major version.

Is repmgr still maintained?

Yes, but slowly. The repository README states that repmgr is maintained by EnterpriseDB and that 5.5.x supports PostgreSQL 13 to 18; that README was updated for PostgreSQL 18 on 2 October 2026. The most recent release is still 5.5.0 from November 2024, and the commits since early 2025 are documentation updates. The published documentation's compatibility table still lists 13 to 17. For existing clusters that is workable. For a new design that has to last five years, it is a reason to prefer a project with a more active release cadence.

pg_auto_failover, Pgpool-II and CloudNativePG

pg_auto_failover adds a monitor: a separate PostgreSQL node running the pgautofailover extension, which holds a state machine for each group, while a keeper process on every data node follows its instructions. It uses synchronous replication by default and can run with just two data nodes. The project's own FAQ calls the monitor a single point of failure: it is needed to register nodes, change replication settings, put nodes into maintenance and carry out a failover, so none of those can happen while it is down. Applications connect with a multi-host connection string and target_session_attrs=read-write. It is under the PostgreSQL Licence, its last release was 2.2 in April 2025, and commits continued through September 2026.

Pgpool-II sits between applications and PostgreSQL. It provides connection pooling, load balancing of read queries across servers, and automatic failover, and its watchdog coordinates several Pgpool-II nodes so the proxy is not itself a single point of failure. It needs at least three Pgpool-II nodes to avoid split brain. It is actively maintained: 4.7.3, 4.6.8, 4.5.13, 4.4.18 and 4.3.21 shipped on 29 September 2026 with security fixes, including one in watchdog message handling.

CloudNativePG is a Kubernetes operator that manages PostgreSQL through the Kubernetes API instead of Patroni, repmgr or Stolon. It promotes a replica itself when the primary fails and keeps three services per cluster: rw for the primary, ro for replicas and r for any instance. Our PostgreSQL Kubernetes operator comparison covers it alongside the Patroni-based operators.

Which PostgreSQL HA tool should you choose?

• Choose Patroni for self-managed clusters on VMs or bare metal, especially across availability zones, where you can run a three-node etcd or Consul cluster.
• Keep repmgr on existing clusters that are stable and well understood, with a witness where nodes span sites. Plan a move to Patroni alongside your next major PostgreSQL upgrade rather than as a separate project.
• Choose pg_auto_failover for small clusters where synchronous replication and simple operations matter more than removing every single point of failure, and you can protect or rebuild the monitor quickly.
• Choose CloudNativePG, or a Patroni-based operator, when PostgreSQL runs on Kubernetes.
• Add Pgpool-II, or a pooler such as PgBouncer with HAProxy, for pooling and routing. Pgpool-II can also manage failover itself; if you pair it with Patroni, let only one of them decide promotions.

Where OSSeva fits

OSSeva supports PostgreSQL under whichever of these you run. OSSeva for PostgreSQL backports security and data-corruption fixes to 11, 12 and 13, and to 14 after 12 November 2026. Patched builds keep the same major version and data directory, so they roll through a Patroni cluster like any minor update, replicas first and then a switchover, and the repmgr package and configuration stay as they are. OSSeva also patches the store under Patroni when it is an end-of-life ZooKeeper, etcd 3.4 or older, or an MPL-licensed Consul release. OSSeva Operate adds monitoring of Patroni, repmgr and DCS quorum. Priced per cluster; book a discovery call for a quote. Our PostgreSQL backup, recovery and HA runbook covers the replication underneath all of these tools.

Frequently asked questions

Patroni vs CloudNativePG: which should we use?

On Kubernetes, CloudNativePG is the simpler choice for most new deployments: failover is handled by the operator through the Kubernetes API, with no Patroni layer. Patroni can also run on Kubernetes, using Kubernetes objects as its store, and is the engine inside the Zalando, Crunchy, Percona and StackGres operators. Off Kubernetes, CloudNativePG is not an option and Patroni is.

Patroni vs Pgpool-II: what is the difference?

Patroni manages PostgreSQL and decides failover through a consensus store. Pgpool-II is a proxy that pools connections, load-balances reads and can trigger failover from its own health checks. They solve different layers. A common design is Patroni for failover with HAProxy or Pgpool-II in front for routing; if you do that, let only one of them make promotion decisions.

Patroni vs pg_auto_failover: which is more reliable?

Patroni has no single coordinating node; the consensus store runs as a cluster of three or more. pg_auto_failover depends on its monitor, which its own documentation describes as a single point of failure for cluster-wide changes. pg_auto_failover is simpler to start with and defaults to synchronous replication. For clusters where failover must work even when one coordination node is lost, Patroni is the safer design.

Is repmgr deprecated?

No. EnterpriseDB still lists itself as maintainer, and the README now covers PostgreSQL 18. But there has been no release since 5.5.0 in November 2024, so plan accordingly for new designs.

Can we migrate from repmgr to Patroni without downtime?

With very little. Patroni documents a procedure for converting an existing cluster: stop repmgrd, bring up the DCS, then start Patroni on the primary and each standby in turn; it detects the running PostgreSQL and starts monitoring it. Handing start-up over to Patroni then needs a restart of each member, which Patroni's documentation suggests doing for standbys immediately and for the primary in a maintenance window. Rehearse it on a copy of the cluster first.

Does Patroni need etcd?

It needs a store, not specifically etcd. Patroni supports etcd, Consul, ZooKeeper and the Kubernetes API. On Kubernetes, using the Kubernetes API removes the need for a separate store.