# repmgr: failover for PostgreSQL, with an extension upgrade path visible in the tree > repmgr is a C suite of tools from EnterpriseDB that wraps PostgreSQL's own replication with cluster management, monitoring and switchover operations, and the current 5.5.x line covers PostgreSQL 13 through 18. What the README does not give you is an install command or a configuration example, so the repository layout does more explanatory work here than the documentation excerpt does. **EnterpriseDB/repmgr** — A lightweight replication manager for PostgreSQL (Postgres) - Repository: https://github.com/EnterpriseDB/repmgr - Website: https://repmgr.org/ - Stars: 1,719 · Forks: 262 - Language: C - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/enterprisedb-repmgr ## What repmgr adds on top of PostgreSQL replication repmgr is described as a suite of open-source tools to manage replication and failover within a cluster of PostgreSQL servers. The stated relationship to PostgreSQL is an enhancement rather than a replacement: it builds on the built-in replication capabilities and adds utilities to set up standby servers, monitor replication, and perform administrative tasks such as failover or switchover. That division of labour is the whole idea. Streaming replication in PostgreSQL gives you a standby that follows a primary. What it does not give you is the cluster-level knowledge: which node is the primary right now, which standbys are healthy, which ones have fallen behind, and what to promote when the primary is gone. repmgr holds that state in its own cluster metadata and uses it to make and record decisions. The intended user is an operations team running PostgreSQL on its own hosts, where automatic failover is a requirement and nobody wants to be the person who runs pg_ctl promote at 03:00. EnterpriseDB maintains it, and the support offering is explicit: 24x7 production support including configuration assistance, installation verification and training for running a replication cluster. That is the commercial arrangement around a GPL tool, not a requirement to use it. ## Version support: 13 through 18 for the 5.5.x line The README states that the most recent repmgr version, 5.5.x, supports all PostgreSQL versions from 13 to 18, and that although it could be used with some older ones, some features might not be available and it is strongly recommended to use the latest version. That range is the single most useful fact for planning an upgrade, and A compatibility matrix is published separately at repmgr.org, and the README links to it as the place to check version and PostgreSQL compatibility rather than guessing. That page is the reference to consult before you commit to a pairing. The release history in this repository is informative about the pace. The tagged releases cluster around late 2024: v5.5.0rc1 on 2024-11-21, v5.5.0 on 2024-11-22, and a packaging tag v5.5.0+debpgdg on 2024-12-19. The last push to the repository was on 2026-10-02 and the repository is not archived, so the source is being worked on. The gap between the two facts is worth holding onto: whatever is in master is not necessarily in a release you can install today. ## What the source tree tells you that the README does not The README is short and points to repmgr.org for the full documentation. The repository layout fills in some of that gap, and a few entries are informative. The top level is flat C with a configure script: compat.c and compat.h hold the version and platform compatibility layer, configfile.c and configfile.h handle configuration parsing, configfile-scan.l is the flex scanner used by that parser, dbutils.c holds database helpers, controldata.c holds control data access, and dirutil.c handles directory operations. pgbackupapi.c is the wrapper over PostgreSQL's backup API. The SQL files are the clearest statement of the project's history. They are named by upgrade step and run from 4.0 through 5.5: ``` repmgr--5.3--5.4.sql repmgr--5.4--5.5.sql repmgr--unpackaged--5.2.sql ``` Three things follow from that listing. First, the extension has a continuous upgrade path since at least 4.0, which matters because upgrading a running cluster through a managed failover tool is a database migration. Second, unpackaged scripts exist, meaning changes that arrive between releases still have a defined path. Third, the naming convention makes it easy to see which release introduced what when reading a support ticket. Test infrastructure is the traditional PostgreSQL one: sql/ holds regression test input and expected/ holds expected output. There is also a contrib/ directory for additional utilities and a doc/ directory of DocBook sources. ## Installation is documented elsewhere, and that is not the same as unavailable This README does not contain an install command, a configure invocation or a configuration file example. It links to the documentation at repmgr.org and, separately, to the compatibility matrix. So the honest description of getting repmgr is: obtain it from the project's own distribution channels rather than by copying a command from this page. The repository publishes a Debian-flavoured tag alongside the plain source tag, which indicates packaged builds exist for at least one distribution, and the package file in the repository root, PACKAGES.md, is the place to look for what is packaged and how. For a first use, the configuration file is the thing to get right, because that is where node identity, cluster membership and the failover behaviour live. The README does not include one, so the documentation site is where to read the parameter names rather than a sample invented here. For a team evaluating this, that gap is a signal about the audience. repmgr is aimed at operators who will read the documentation and run the drills, not at someone wanting a two line install. ## Limitations that follow from the design The first limitation is architectural rather than a bug. repmgr manages physical replication: standby servers, promotion, switchover. If your replication topology is logical, with subscriptions and selective table shipping, repmgr is not the tool, because the cluster metadata model assumes standbys that can be promoted to primary. The second is the split brain question, which every automatic failover tool has and which repmgr's design makes concrete. The tool makes the promotion decision and records it, so the operational discipline around it is quorum and fencing: repmgr can decide, but it cannot stop a node that still believes it is primary. Automatic failover with repmgr assumes your monitoring and your fencing are better than your primary's failure detection, and if they are not, you have replaced an outage with a split brain. The third is the single-binary dependency on a consistent view of time and reachability. Decision-making during a network partition is where these tools behave worst, and the configuration around witness servers and priority exists for exactly that case. The fourth is the release gap noted above. The last tagged release is from late 2024 while the repository has seen pushes into 2026, so if you need a fix that is not in 5.5.0 you are looking at building from master. None of these make repmgr a poor choice for a physical replication cluster. They make it a choice that requires drills. ## How the alternatives differ There are two serious alternatives, and they differ in where the decision logic lives. The third option is managed PostgreSQL, where somebody else runs the failover. That removes the entire problem, along with the control, and is the right answer for teams without a DBA. For a team that already understands physical replication and wants a supported, scriptable failover without adding a distributed configuration store, repmgr sits in a sensible place. ## Licence, governance and what to check The README states that repmgr is distributed under the GNU GPL 3 and maintained by EnterpriseDB, and the repository carries a LICENSE file described as GNU GPL3 details plus a separate COPYRIGHT file. Repository metadata flags the licence as a custom type that GitHub cannot classify, which is a classification artefact rather than a statement that the terms are unusual; the LICENSE file is the authoritative text and this is a note rather than legal advice. Project governance is visible in the repository rather than documented at length. CONTRIBUTING.md describes how to contribute, CREDITS and the README list the core team and past contributors, and there is a Google group for discussing contributions or issues alongside the GitHub issue tracker for bugs. The tree also carries files most projects do not, and they are the ones to read before contributing: HISTORY is a summary of changes in each release, TODO.md, FAQ.md, and the expected/ and sql/ regression directories that tell you whether your change would break a test. Before adopting, check four things. Confirm your PostgreSQL major version sits between 13 and 18 for the 5.5.x line. Read the compatibility matrix rather than trusting the README range alone. Run a switchover drill and a failover drill before you need them. And decide who responds when the tool makes the wrong call, because EnterpriseDB's 24x7 support is a commercial offering and community channels are a Google group and the issue tracker. ## Conclusion Use repmgr if you run a PostgreSQL cluster on physical replication, meaning standbys you promote and demote, and you want failover decisions driven by a tool that understands cluster membership rather than by a shell script watching for a dead primary. Do not choose it for logical replication workloads, and do not read the absence of install instructions as a signal about package availability, since the repository publishes a Debian package tag. Verify first which PostgreSQL major version your cluster runs, because 5.5.x supports 13 through 18 and older versions lose features, then confirm the failover drills you plan to run against your monitoring system, since repmgr's job is to make the promotion decision at the moment it matters. ## FAQ ### Which PostgreSQL versions does repmgr 5.5.x support? The README states that the most recent repmgr version, 5.5.x, supports all PostgreSQL versions from 13 to 18. Older versions may work with some features unavailable, and the project strongly recommends using the latest version. A compatibility matrix is published at repmgr.org. ### Who maintains repmgr and what support is available? repmgr is distributed under the GNU GPL 3 and maintained by EnterpriseDB. EnterpriseDB provides 24x7 production support including configuration assistance, installation verification and training for running a replication cluster, as a commercial support offering. ### How do I upgrade the repmgr extension in an existing cluster? The repository carries SQL upgrade scripts named by step, from repmgr--4.0--4.1.sql through repmgr--5.4--5.5.sql, along with unpackaged scripts such as repmgr--unpackaged--5.2.sql. The HISTORY file summarises changes in each release, and the documentation at repmgr.org covers the upgrade procedure. ### When was the latest repmgr release published? The tagged releases are v5.5.0rc1 on 2024-11-21, v5.5.0 on 2024-11-22 and a packaging tag v5.5.0+debpgdg on 2024-12-19. The last push to the repository was on 2026-10-02 and the repository is not archived. ### What licence does repmgr use? The README states repmgr is distributed under the GNU GPL 3, with the LICENSE file at the repository root and copyright information in a separate COPYRIGHT file. Repository metadata lists the licence as a custom type GitHub cannot classify, so the LICENSE file is the authoritative text. ## Sources - [EnterpriseDB/repmgr on GitHub](https://github.com/EnterpriseDB/repmgr) - [Issues](https://github.com/EnterpriseDB/repmgr/issues) - [Project website](https://repmgr.org/) - [README](https://github.com/EnterpriseDB/repmgr/blob/master/README.md) - [Releases](https://github.com/EnterpriseDB/repmgr/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/enterprisedb-repmgr