pgmoneta: A C-Based Backup and Restore Tool for PostgreSQL That Skips the PostgreSQL Binaries

What pgmoneta Solves and Who It Is For

pgmoneta addresses a specific operational pain: backing up PostgreSQL clusters without depending on the PostgreSQL server binaries. The README states that pgmoneta does not rely on PostgreSQL binary. That is a meaningful distinction from tools like pg_dump or pg_basebackup, which ship with PostgreSQL and require a matching version. pgmoneta is a separate daemon, written in C, that talks to PostgreSQL directly. It is aimed at database administrators and site reliability engineers who manage multiple clusters and want a single tool for full backups, incremental backups, WAL shipping, and restore, all with a Prometheus endpoint for monitoring. The target platforms are Linux distributions and BSDs: Fedora 42+, RHEL 10.x, Rocky Linux 10.x, AlmaLinux 10.x, FreeBSD, and OpenBSD. If you run PostgreSQL on those systems, pgmoneta is a candidate. If you run on Windows or macOS, the README lists no support.

The Mechanism: Process Model, Shared Memory, and libev

The architecture is described in the README's overview and the linked architecture document. pgmoneta uses a process model, not a thread-per-connection model. It shares state across processes via shared memory and uses atomic operations to track state. Network interactions are handled by libev, an event loop library that is known for speed and low overhead. This design suggests a daemon that can handle many concurrent connections without the complexity of thread synchronization. The worker pool feature, mentioned in the feature list, accelerates operations like backup, restore, delete, and verify. The README does not specify how many workers or how they are configured, but the existence of a worker pool implies that operations can be parallelized. The use of C and libev points to a focus on performance and resource efficiency, which is typical for infrastructure tools that run continuously. The shared memory model is interesting because it means the daemon can coordinate multiple processes without a central coordinator, which could be a strength for reliability, but it also means that a crash in one process might affect shared state.

Installation and First Run: Commands and Config Keys

The quickest path is the PostgreSQL YUM repository. For Fedora, RHEL, Rocky Linux, or AlmaLinux 10, you add the PGDG repository with a dnf command, then install pgmoneta with 'dnf install -y pgmoneta'. The README warns that pgmoneta does not rely on PostgreSQL binaries, so you only need PostgreSQL if you want to test the tool. If you do, you must disable the distribution's PostgreSQL module and install a specific version, for example PostgreSQL 18. For a source build, you need clang or gcc, cmake, make, libev, OpenSSL, zlib, zstd, lz4, bzip2, systemd, libssh, and libarchive. The release build commands are straightforward: clone the repo, create a build directory, run cmake with the clang compiler and an install prefix, then make and install. A debug build uses cmake with -DCMAKE_BUILD_TYPE=Debug, and the README says to set 'log_level' to 'debug5' for verbose output. The configuration file is documented separately, but the README points to a Getting Started guide and a Configuration document. The presence of a 'log_level' option indicates that logging is configurable, and 'debug5' is the most verbose level.

Backup Features: Full, Incremental, and WAL Streaming

pgmoneta supports full backups with tablespace support, and incremental backups for PostgreSQL 14 and later. For PostgreSQL 17 and later, incremental backups also include tablespace support. The README mentions 'intuitive backup chain management', which likely means that incremental backups are stored as a chain of changes from a base backup, and you can restore to any point in that chain. WAL streaming is a core feature: pgmoneta can continuously receive WAL segments from the PostgreSQL server, which is essential for point-in-time recovery. The tool also includes WAL tools to inspect WAL records and optionally filter them out. This is a different approach from simple file-level backups; it is closer to a continuous archiving solution. The combination of full backups, incremental backups, and WAL streaming gives you a complete backup strategy. However, the README does not specify the format of incremental backups or how the chain is managed. You would need to consult the architecture document to understand the exact mechanics.

Security and Operations: Encryption, TLS, and Prometheus

pgmoneta includes AES encryption for backups at rest, which is a critical feature if you store backups on untrusted media. It also supports TLS v1.2+ for both client and server connections, which secures communication between pgmoneta and PostgreSQL, as well as between pgmoneta and its management tools. The user vault is a feature for managing PostgreSQL credentials securely, which suggests that pgmoneta stores credentials in an encrypted or protected manner, rather than in plain text configuration files. For operations, there is a Prometheus metrics endpoint, which is essential for integrating with monitoring systems like Grafana. There is also a web console for inspecting metrics, and remote management via 'pgmoneta-cli' or 'pgmoneta-mcp'. The MCP server/client is interesting: it allows interaction with the core using natural language, which is a modern twist for a backup tool. The offline detection of unreachable instances means pgmoneta can mark a PostgreSQL server as down if it cannot connect, which is useful for alerting.

Limitations and Failure Modes

The most obvious limitation is platform support. The README lists only Linux distributions and BSDs. If you run PostgreSQL on Windows or macOS, pgmoneta is not for you. Another limitation is the dependency on PostgreSQL version for incremental backups. Incremental backups require PostgreSQL 14 or later, and tablespace support for incremental backups requires PostgreSQL 17 or later. If you run an older PostgreSQL version, you are limited to full backups and WAL streaming. The README does not describe a restore dry-run mode or a way to validate a backup without actually restoring it. This is a gap: you would need to test restores in a staging environment to be confident. The README also does not mention how pgmoneta handles network partitions or crashes during a backup. The process and shared memory model could be a source of subtle bugs if a process crashes while holding a lock. The documentation is extensive, but the README is just a summary; you must read the architecture and configuration documents to understand failure modes.

Alternatives: pgBackRest and pg_dump

The most direct alternative is pgBackRest, a popular open-source backup tool for PostgreSQL. pgBackRest also supports full and incremental backups, WAL archiving, and point-in-time recovery, but it is written in Perl and C, and it requires a dedicated repository for backups. pgmoneta differs in that it is written entirely in C and does not rely on PostgreSQL binaries, which might be a lighter dependency. pgBackRest has a longer history and a wider user base, but the README does not provide a comparison. Another alternative is the built-in 'pg_dump' for logical backups, but that does not support incremental backups or WAL streaming. For physical backups, 'pg_basebackup' is a standard tool, but it requires the PostgreSQL server to be running and does not provide incremental backups or a Prometheus endpoint. pgmoneta's advantage is its all-in-one design: it handles backups, WAL streaming, encryption, and monitoring in a single daemon. The trade-off is that you are betting on a project that is less established than pgBackRest, though the release cadence (0.21.0 in April 2026) suggests active development.

Maintenance and Upgrade Cost

The project is actively maintained, with releases on a roughly quarterly basis: 0.19.1 in August 2025, 0.20.0 in January 2026, and 0.21.0 in April 2026. The license is BSD-3-Clause, which is permissive and allows commercial use with attribution. There is no mention of a commercial support contract, so you rely on community support via GitHub discussions, which are linked in the README. Upgrading pgmoneta is likely a matter of installing the new package or rebuilding from source. The README does not describe a migration path for configuration files, but the configuration format is likely stable across minor versions. The dependency list is long, but standard for a C project. The use of systemd integration means you can manage it as a service, which is a plus for operations. The maintenance cost is moderate: you need to stay current with releases to get bug fixes and new features, but the BSD license and active development reduce the risk of abandonment.

Editorial conclusion

Adopt pgmoneta if you run PostgreSQL 14 or later on Fedora, RHEL, Rocky Linux, or AlmaLinux, and you want a backup daemon that does not rely on PostgreSQL binaries, with incremental backups and a built-in Prometheus endpoint. Avoid it if you need a GUI, a Windows installer, or if you prefer a tool backed by a commercial vendor with a longer support history. Before deploying, verify that your exact PostgreSQL version is supported, especially for incremental backups and tablespace handling, and test the restore procedure on a non-production cluster, since the README does not document a restore dry-run mode.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes