Patroni vs repmgr: when each one is the right choice for your PostgreSQL failover
If your team runs PostgreSQL on virtual machines and must pick a failover manager, choose Patroni when you already operate a distributed configuration store such as etcd, Consul, ZooKeeper or Kubernetes, and you want a REST API that your monitoring and automation can call for health checks, cluster status, switchovers and failovers. Patroni is MIT licensed and is a template you configure for each deployment rather than a finished product, so it suits teams with the skills to own that configuration. Choose repmgr when you want an EDB-maintained GPL-3 toolset that handles standby setup, replication monitoring and switchovers without introducing a separate coordination cluster.
The decision turns on four things: how each tool prevents split-brain in your design, which configuration store you already run and can keep healthy, which PostgreSQL major versions you must support, and what your team already knows how to operate. Check the split-brain behavior against your own network and fencing design, not only the feature list. Confirm the supported PostgreSQL range for the release you plan to deploy: the Patroni documentation lists PostgreSQL 9.3 to 18, while the repmgr 5.5.x README lists 13 to 18, so older clusters and PostgreSQL 13 or earlier need separate evaluation.
Keep one point in view throughout: PostgreSQL does not detect a primary failure or notify the standby on its own, so automatic failover requires either Patroni or repmgr, or another external tool. A manual switchover process is not automatic failover. Before you commit, ask each vendor or community to confirm how its failover behaves under a network partition in your topology, and test that scenario in a non-production environment. The Patroni documentation is the natural next read for the Patroni side.
Which failover manager fits which scenario
This table maps common team situations to the failover manager that usually fits better, with the condition that changes the answer. Read each row as a starting point: the conditions column names what must be true, and the design questions to confirm against the documentation for your exact version.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| You already run an etcd, Consul or ZooKeeper cluster | Patroni | Patroni uses one of these stores as its distributed configuration store, so leader election relies on infrastructure your team already operates. Confirm that the store is sized and monitored for this extra load. |
| Your team already runs Kubernetes and wants PostgreSQL managed alongside workloads | Patroni on Kubernetes or a Kubernetes-native operator | Patroni can use Kubernetes as its configuration store, but if the databases should run inside Kubernetes, compare operators such as CloudNativePG before committing to a VM-based pattern. |
| No configuration store exists and you want a fixed set of tools for failover | repmgr, if you accept its witness and fencing design | repmgr manages standbys, monitoring and switchover without an external store. Confirm how it handles witness placement and fencing for your version in the repmgr documentation, because that design becomes your responsibility. |
| A small estate of PostgreSQL pairs run by DBAs who prefer explicit commands | repmgr | Its command-line workflow covers standby setup, replication monitoring and switchover, which maps well to hand-run operations. Confirm the supported PostgreSQL range first, since repmgr 5.5.x supports PostgreSQL 13 to 18. |
| Many clusters that need one consistent automation layer and a REST API for orchestration | Patroni | Patroni exposes a REST API for health checks, status, switchover, failover, restarts and reinitialization, which suits scripted fleet operations. Confirm your tooling can call it securely. |
| You need standby clusters, synchronous quorum commit or watchdog-based fencing | Patroni | Patroni documents standby clusters, quorum commit and watchdog devices. Verify each feature against your PostgreSQL version and your hardware, since watchdog behavior depends on the host. |
| You need a vendor-maintained toolset with the maintainer as the support path | repmgr | repmgr is maintained by EnterpriseDB under GPL-3. Ask EnterpriseDB or your provider what support, if any, applies to your deployment. Patroni is MIT licensed and community maintained. |
| Your PostgreSQL version is 13 or 12 and you need to stay on it | Confirm before choosing | PostgreSQL 13 is listed as unsupported in the versioning policy. Check the currently supported Patroni and repmgr ranges for your version before committing to either. |
How Patroni and repmgr each decide which node is primary
Patroni and repmgr both promote a standby when a primary fails, but they keep the decision state in different places. Patroni relies on a distributed configuration store and a leader key, while repmgr keeps its cluster metadata in PostgreSQL itself and can use a witness node. The cards below cover the parts that shape day-two operations: what to back up, what stops working during an outage, and what your team must run.
Patroni agent on each node
Every PostgreSQL node runs a Patroni Python process that manages the local PostgreSQL instance, writes its state to the configuration store and decides whether it should hold the leader role. Because each node runs its own agent, a host that loses its agent stops reporting, and Patroni treats it as unavailable. Check how your team will deploy, pin and upgrade this agent on every host, since Patroni requires configuration for each deployment. Patroni 4.1.5 and 4.0.11 were both released on August 12, 2026, so confirm which release line your change process targets.
Configuration store and leader key
Patroni stores cluster state and the leader key in ZooKeeper, etcd, Consul or Kubernetes. The leader key determines which node may accept writes, so the store becomes the arbiter during a failover. If the store is unreachable, the current primary may demote itself to protect against split-brain, which can make the whole cluster read-only until the store recovers. Back up the store alongside the database, and rehearse what happens when its quorum is lost. Confirm the exact demotion behavior for your chosen store and Patroni version.
REST API for health and switchover
Patroni exposes a REST API for health checks, cluster status, configuration, switchover, failover, restarts, reloads and reinitialization. Load balancers and monitoring tools can use it to route traffic to the current leader, and operators can trigger planned switchovers without touching SQL. Treat the API as a privileged control surface: restrict network access, authenticate callers and log changes. Confirm which endpoints your monitoring and automation rely on before you standardize on them.
repmgr node tools and metadata schema
repmgr runs as command-line tools on each PostgreSQL server, and it records cluster membership, roles and replication history in its own metadata schema inside the database. Backing up that schema is part of backing up the cluster, because a restored node may otherwise disagree with its peers about who is primary. Its switchover and failover commands run on the nodes themselves, so the operator's runbook must name which host runs each step. repmgr 5.5.x supports PostgreSQL 13 to 18, so check the supported version range before choosing a major release.
repmgr witness node
A repmgr witness is a lightweight PostgreSQL instance that does not hold data but votes during failover, so a two-node cluster does not promote on a partition that only one node can see. The witness is a single point of decision for the vote, and its loss removes the tie-breaker without stopping replication. Place it outside the failure domain of the primary and standby, and alert on its state. Confirm with your own network design how a witness interacts with your data center or cloud zone layout before relying on it for automatic failover.
Patroni vs repmgr on split-brain, versions, licensing and operations
This table compares Patroni and repmgr on the facts that decide a PostgreSQL failover design on virtual machines: license, maintainer, supported versions, how leader election is coordinated, and day-two tooling. Read each row against your own PostgreSQL version and fencing requirements, and treat any cell marked for confirmation as a question for the vendor documentation before you commit.
| Criterion | Patroni | repmgr |
|---|---|---|
| License | MIT licensed | GPL-3 licensed suite of tools |
| Maintainer | Originated at Zalando; open-source project with a published release history | Maintained by EnterpriseDB |
| Supported PostgreSQL versions | Runs PostgreSQL 9.3 to 18 per its documentation; confirm the exact range for your release | repmgr 5.5.x supports PostgreSQL 13 to 18; older PostgreSQL versions are unsupported by the current line |
| Configuration store or witness model | Uses ZooKeeper, etcd, Consul or Kubernetes as its distributed configuration store for leader election | Uses its own cluster metadata and a witness server; confirm the witness and fencing design for your version in the repmgr documentation |
| Synchronous replication | Supported, including quorum commit | Supported for standby setup and monitoring; confirm how commit policy is managed in your version |
| Standby clusters | Supported | Confirm standby cluster support and layout in the repmgr documentation |
| Watchdog support | Supports watchdog devices to help prevent split-brain | Confirm watchdog or fencing options for your version; do not assume parity with Patroni |
| REST API | Exposes a REST API for health checks, cluster status, configuration, switchover, failover, restarts, reloads and reinitialization | Command-line tooling for standby setup, replication monitoring and switchover; confirm whether any HTTP interface exists for your deployment |
| Switchover and failover tooling | Switchover and failover are available through the REST API and Patroni tooling | Running switchovers is part of the toolset; confirm the failover procedure and automatic behavior for your version |
| Citus support | Supported since Patroni 3.0 | Not a stated feature; confirm with the vendor if you need Citus |
What the licenses and editions mean for your deployment
Patroni is released under the MIT license, a permissive license that lets you run, modify and redistribute the software without copyleft obligations on your changes. Patroni describes itself as a template for high availability PostgreSQL solutions written in Python, so each deployment needs its own configuration before it does anything useful. That configuration becomes part of your deployment record.
- Permissive terms: MIT terms let you patch or wrap Patroni in internal automation without releasing that code under the same license.
- Per-deployment configuration: Your team writes the cluster definition, store endpoints and replication settings, so these files belong in change control and audit evidence.
- Current release lines: Patroni 4.1.5 and 4.0.11 were both released on August 12, 2026, giving you two maintained lines to choose from when planning upgrades.
- Store dependency: Patroni relies on ZooKeeper, etcd, Consul or Kubernetes as its distributed configuration store, so the license and support terms of that store also belong in your inventory.
- Community support: The supplied facts do not include a paid Patroni edition, so confirm any commercial support terms directly with the vendor or with your implementation partner.
Before you commit, confirm which release line your team will standardize on and who supports the configuration store in your environment.
repmgr is a suite of tools under the GPL-3 license that manages replication and failover across a cluster of PostgreSQL servers. Its tools cover standby setup, replication monitoring and switchovers, and EnterpriseDB maintains the project. GPL-3 is a copyleft license, so the terms that matter most are the ones that apply when you distribute modified copies.
- Copyleft obligations: Distributing modified repmgr binaries or source can trigger GPL-3 source-availability duties, so ask your counsel which of your internal uses count as distribution.
- Single vendor maintenance: EnterpriseDB maintains the repository, so release decisions and maintenance priorities sit with one company. Check its release cadence and advisory channel before you depend on it.
- Version coverage: repmgr 5.5.x supports PostgreSQL 13 to 18, which covers the current major versions, but PostgreSQL 13 is already unsupported by the PostgreSQL project.
- Integrated toolset: Standby setup, monitoring and switchover ship in one suite, which reduces the number of separate components your team must license, patch and track.
- Commercial terms: The supplied facts do not describe a paid repmgr edition, so confirm any EnterpriseDB support terms directly with the vendor before you rely on them in a contract.
Before you commit, confirm the repmgr version that matches your PostgreSQL major version and the license position your legal team has agreed for your deployment model.
PostgreSQL is released under the PostgreSQL License, a liberal open source license similar to the BSD and MIT licenses. The license itself places few conditions on how you use the database, so your cost and risk come mostly from support windows, upgrade effort and the tools you run around it. Both Patroni and repmgr must keep pace with the major versions you run.
- Permissive database license: Like the failover managers, the PostgreSQL License carries no copyleft requirement, so internal modifications stay within your control.
- Support windows: PostgreSQL 14 is supported until November 12, 2026, 15 until November 11, 2027, 16 until November 9, 2028, 17 until November 8, 2029 and 18 until November 14, 2030.
- Release cadence: PostgreSQL releases a new major version about once a year and minor releases at least once every three months, so plan for regular minor updates in every cluster.
- Upgrade path: Minor releases replace executables and require a restart, while major upgrades use dump and restore, pg_upgrade or logical replication, and each tool's compatibility must be checked before you move.
- Paid support: The supplied facts do not describe a paid PostgreSQL edition, so confirm commercial support options with the vendors or service providers you are considering.
Before you commit, map each cluster's PostgreSQL major version to its end-of-support date and confirm which failover manager release supports that version.
What drives the running cost of each failover manager
The software itself costs nothing under either license, since Patroni is MIT licensed and repmgr is GPL-3, so the running cost of each option comes from the infrastructure and people around it. Budget for the virtual machines that run PostgreSQL and the failover manager, the configuration store that Patroni depends on (an etcd, Consul, ZooKeeper or Kubernetes cluster, typically three members), any witness host that repmgr deployments use for quorum, the monitoring and alerting stack, backup storage and the DBA and platform time to operate all of it. Those are the lines a quote will price, and the ownership of each one differs between the two tools.
Most of the cost is one-time: architecture design, build, runbooks, and failover and switchover testing against the real cluster, including fencing and the watchdog settings you choose for split-brain protection. The recurring costs are patching the operating system, PostgreSQL minor releases (which PostgreSQL ships at least once every three months), manager upgrades, and a major PostgreSQL upgrade roughly once a year, with each major version supported for five years. Ask every provider how many clusters the scope covers, whether the configuration store is hosted and maintained by them or by you, which monitoring and backup tools are included, and who is on call for a failover at 3 a.m.
Cost rises with the number of clusters, the number of environments that must be kept in step, and any requirement for fully automated failover that needs a tested fencing design. It falls when the team standardizes on one configuration pattern and one upgrade cadence across clusters. Before accepting a quote, confirm in writing the supported PostgreSQL versions for the chosen tool, the upgrade path you will follow, and whether PostgreSQL's versioning policy dates fit your planned upgrade window. Ask for the cost of the first major upgrade separately, because that is the event most teams underestimate.
Moving between Patroni and repmgr without losing a standby
This sequence moves a live PostgreSQL cluster from one failover manager to the other while keeping the data files, replication users and backup repositories intact. Each step ends with a check you can verify before the old tool is removed.
Inventory the current topology and replication settings
Your DBA or platform engineer records every node, its role, the replication slots, the synchronous standby names, the authentication rules in pg_hba.conf, the connection path used by applications (virtual IP, HAProxy or PgBouncer) and the backup repository and its retention. Export the current configuration files so each setting can be compared later. The step is done when someone other than the author can read the inventory and rebuild the cluster layout from it without asking questions.
Build the new manager's configuration store in a test environment
Stand up a copy of the cluster in a non-production environment. For Patroni, this means a distributed configuration store (etcd, Consul, ZooKeeper or Kubernetes) and a per-node Patroni configuration file. For repmgr, this means a repmgr.conf per node, a repmgr metadata schema, and a witness server if you want one for quorum decisions. Your team confirms the failover behavior it expects from each option against the vendor documentation before moving on. The step is done when the test cluster elects a leader and reports healthy status on every node.
Rebuild standbys under the new tool
Rather than converting live nodes in place, bring standbys under the new manager one at a time. Each standby is re-registered with the new tool so that it attaches to the existing primary using the replication user you already have. Confirm replication lag and synchronous commit state after each node joins. The step is done when every standby reports streaming status to the new manager and the primary shows the expected replication entries.
Run controlled switchovers and failover tests
Run planned switchovers between every pair of nodes, then simulate a primary failure in the test environment and in a maintenance window in production. Record the time to promote, whether the old primary rejoins as a standby without manual repair, and whether applications reconnect through the proxy or virtual IP. Check that fencing or watchdog behavior prevents two primaries from accepting writes. The step is done when the test log shows clean switchovers and a failover with no split-brain condition, and the runbook has been updated with the observed steps.
Cut over application connections through the proxy or virtual IP
Application traffic moves only after the new manager has passed the tests above. Change the health check endpoints behind HAProxy or the virtual IP ownership so they follow the new leader, and confirm that PgBouncer or any connection pooler points at the correct host. Run read-only and read-write probes from each application tier. The step is done when application logs show successful connections to the new leader and the old endpoint no longer receives writes.
Rebuild health checks, monitoring and runbooks for the new tool
Health checks, alerts and on-call runbooks were written for the old tool and must be replaced, not carried over. Point monitoring at the new manager's status interface (Patroni's REST API or repmgr's cluster show and event reporting), define alerts for replication lag, leader changes and missing standbys, and rewrite the failover and switchover procedures. Your on-call team rehearses the new runbook once. The step is done when alerts fire in a controlled test and the rehearsal finishes using only the new documentation.
Retire the old tool after a stable observation period
Once the cluster has run under the new manager long enough for your change process to accept it, stop and remove the old tool's services, configuration and scheduled jobs on every node. Keep the old configuration in your change record. Confirm that backup jobs still run against the same repository and that the restore test has been repeated. The step is done when the old services are gone, backups restore successfully, and the change record references the final configuration.
Decide on any PostgreSQL major version change as a separate project
The manager change does not require a PostgreSQL major version change, and it should not be bundled with one. Data files, replication users and backup repositories carry over unchanged when the major version stays the same. If you also plan to upgrade, treat it as its own project with its own rollback plan, using the PostgreSQL upgrade methods in the official documentation (pg_upgrade, dump and restore, or logical replication). Confirm the target version against the PostgreSQL versioning policy before scheduling it. The step is done when the upgrade decision is recorded separately and the failover manager migration is closed.
What implementing each tool involves and where projects run long
A Patroni deployment on virtual machines is mostly a distributed configuration store project with PostgreSQL attached. Patroni supports ZooKeeper, etcd, Consul or Kubernetes as its store, so the first decision is which store your organization already runs and can keep healthy. You then need a store cluster with its own quorum, a patroni.yml per node with scope, name, restapi and postgresql sections, and a consistent way to distribute those files. Patroni's REST API is the integration point for load balancers and monitoring, so health check endpoints must be wired into HAProxy or similar, and the team must decide which endpoint answers for the primary and which for replicas. Choose a watchdog device deliberately: Patroni documents watchdog support, and the device determines how a node fences itself when it loses its store. Confirm that your Python 3.11 or later runtime is at Patroni 4.1.1 or 4.0.8 or later, because the documentation notes a memory allocation issue on memory-restricted hosts that those releases address. Patroni 4.1.5 and 4.0.11 were both released on August 12, 2026.
A repmgr deployment is smaller in moving parts but puts more of the failover logic into your own procedures. The work centers on registering each node with repmgr primary register and repmgr standby register, cloning standbys, setting up replication monitoring, and designing a witness node so that a partitioned primary cannot be mistaken for a dead one. Repmgr's automatic failover depends on the witness and on the repmgrd daemon running on every node, so the team must write and test the promotion, rejoin and fencing steps around it. Expect to build your own dashboards and alert paths, and confirm which repmgr 5.5.x release matches your PostgreSQL version, since the README lists support for PostgreSQL 13 to 18.
The long points are common to both tools. Fencing and split-brain tests take longer than teams plan for, because each network partition, store outage and forced stop must be reproduced and the expected primary confirmed afterward. Configuration store outages, for Patroni, and witness or monitoring gaps, for repmgr, tend to surface only under test. Application connection handling, including pooler configuration and retry behavior on failover, often becomes a project of its own. The team must supply named owners for the database, the network and the on-call rota, a test environment that mirrors production topology, and access to production change windows for cutover and failover drills.
Questions DBAs and platform leads ask before choosing a failover manager
Does Patroni or repmgr cost less to run?
Neither carries a license fee for the core tool: Patroni is MIT licensed and repmgr is GPL-3, so the recurring cost is mostly the people who operate it and the infrastructure underneath. Patroni adds a distributed configuration store (etcd, Consul, ZooKeeper or Kubernetes), which is another cluster to build, patch and monitor. repmgr runs on the PostgreSQL servers themselves, so it usually means fewer moving parts. Ask any vendor or partner to price the configuration store, the monitoring stack and the on-call load as separate line items, because those drive the running cost more than the software does.
How long does a failover manager implementation take?
The duration depends on how many clusters you run, how many environments need to match, and how much of the backup, monitoring and client routing work is in scope. A single cluster with an existing configuration store is a very different project from a fleet with new etcd clusters, new load balancing and tested failover runs. DeployOpen works from a written, fixed scope with agreed deliverables and timelines, so ask for the timeline in that document rather than a generic estimate. Include time for failover drills, which are where most problems surface.
Can a small team operate Patroni or repmgr without outside help?
A small team can operate repmgr with solid PostgreSQL skills, since its tooling works directly on the database servers and its switchover commands are straightforward. Patroni is also workable, but the team must also run and understand the configuration store, its REST API and the watchdog or fencing choices, so the skill set is broader. Before deciding, check who on the team can answer these questions at 2 a.m., and whether backups and restores have been tested end to end. Outside help is most useful for the first build, the runbooks and the first failover drill.
Can a repmgr cluster move to Patroni later?
A move is possible but it is a planned migration, not a switch. The cluster must be re-architected around a configuration store, the failover logic and client connection routing change, and the team must retest switchover and failover from scratch. Plan a maintenance window, a rollback path and a dry run on a copy of production. Ask for the migration steps and the test evidence in writing before committing, and treat the move as a project with its own scope, not an afterthought.
Which PostgreSQL versions does each tool support?
repmgr 5.5.x supports PostgreSQL 13 to 18, according to its README, while Patroni runs PostgreSQL 9.3 to 18 according to its documentation. Support for the PostgreSQL server itself follows the core project's policy: PostgreSQL 14 is supported until November 12, 2026, PostgreSQL 15 until November 11, 2027, and PostgreSQL 18 until November 14, 2030. Plan the failover manager and the PostgreSQL major version together, because a cluster on PostgreSQL 14 will need a major upgrade within months, and that changes the failover setup as well.
Does split-brain protection differ between Patroni and repmgr?
Yes, and the difference matters most in a network partition. Patroni uses leader election through its configuration store, so a node only holds the primary role if it holds the leader key, and it can use a watchdog device to fence a node that loses coordination. repmgr relies on its witness and monitoring design and on the operator's fencing policy, so you must verify how the old primary is stopped or isolated before promotion. Ask the implementer to show the partition test results and to document which component decides leadership.
Do we need a consultant to implement either one?
You do not have to hire one, but an outside team is most useful when the scope is large, the environment is regulated, or the internal team has not run automatic failover before. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms inside your own infrastructure, typically under a fixed scope agreed in writing, and ongoing support is available as a retainer. Whoever you choose, ask for the deliverables in writing: configuration, runbooks, failover test reports, backup restore tests and handover training.
How DeployOpen helps you choose, implement and run your PostgreSQL failover
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Patroni vs repmgr, we start from your VMs, your network and your existing PostgreSQL estate, then set out in writing how the failover design will be built, tested and handed over.
How we scope
- Confirm which PostgreSQL major versions run in your estate and check them against the supported window in the PostgreSQL versioning policy.
- Record the configuration store you already operate, such as etcd, Consul or ZooKeeper, or whether you need one at all.
- Agree in writing how switchover, failover and split-brain tests will be defined before any build work starts.
How we build
- Configure the leader election, watchdog and synchronous replication settings you have chosen, with each setting documented against your environment.
- Set up the failover manager on your VMs and test automatic failover, planned switchover and fencing of the former primary.
- Integrate connection routing and client authentication with your existing identity and certificate processes where your scope includes them.
How we hand over
- Deliver runbooks for switchover, reinitialization, version upgrades and recovery, written for the teams who will operate the cluster.
- Document the configuration, test results and evidence your auditors or internal reviewers will ask for, without claiming any certification.
- Walk your operators through failover drills so the first real event is not the first time anyone has run the procedure.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
- Plan minor and major PostgreSQL upgrades as scoped work, with the upgrade method and rollback steps agreed beforehand.
- Ask any provider, including us, to confirm in writing which components they will support after go-live and for how long.
