pgmoneta, the PostgreSQL backup tool that never calls a PostgreSQL binary

Incremental backup needs PostgreSQL 14 and tablespaces need 17

Two PostgreSQL version floors sit inside one feature bullet, and they are different numbers.

Incremental backup is available for PostgreSQL 14 and later. Tablespace support for that incremental path is called out separately as PostgreSQL 17 and later. Full backup carries tablespace support with no version qualifier at all.

So there are three bands rather than two. On PostgreSQL 14 through 16 you get incremental backup without tablespace coverage. On 17 and later you get both. On anything older than 14, incremental backup is simply not there, and the fallback is full backup plus WAL streaming. The parenthetical is the only place any of this is written down, so the version check has to happen before you design a retention policy rather than after.

Compression and encryption apply to both paths, so an incremental chain and a full backup end up in the same format, which is what lets a restore walk from a full image through the chain to a chosen point in time.

The RPM recipe is written for EL 10 and nothing else

The packaged install is documented for exactly one major version of one distribution family.

The RPM instructions name the PGDG repository and give a concrete command, with the repo package URL pinned to EL-10-x86_64 and the surrounding text naming Fedora, RHEL, Rocky Linux, and AlmaLinux 10. Every other route on the page is for compiling from source.

That leaves the tested platforms list only partly covered by an install path. Fedora 42+ appears there, and so do FreeBSD and OpenBSD, but the RPM recipe is written for EL 10 and a Fedora user on Fedora 42 has to edit the distribution segment out of that URL. There is no documented apt, dnf for other majors, or pkgsrc route anywhere in the file. Both BSDs are in the tested list with nothing but the source build behind them.

The source build is not short either. Thirteen required dependencies are listed, from clang and cmake through libev, OpenSSL, four compression libraries, systemd, libssh, libarchive, and rst2man for the man pages, with pandoc and texlive optional for documentation.

It never shells out to a PostgreSQL binary

One sentence in the installation section decides the whole architecture: pgmoneta does not rely on PostgreSQL binary.

That is a different design from tools that wrap pg_basebackup or shell out to pg_dump. Nothing here needs the server installation to be present, which is why the next paragraph can offer installing PostgreSQL 18 as an optional convenience purely so you have something to point the tool at. On RPM systems that convenience has its own cost, because the distribution ships a PostgreSQL module you are told to remove first with dnf -qy module disable postgresql, then install postgresql18 and postgresql18-server.

The overview supports the same picture from the implementation side: a process model, shared memory across processes, libev for network interaction, and atomic operations for state. A tool with no server binary to lean on has to do the protocol work itself, which is part of why the dependency list carries libssh and libarchive and nothing PostgreSQL-specific.

The tree matches that shape. src/ holds the code, doc/ holds the linked guides and the user manuals in English and Spanish, test/ holds the tests, benchmarks/ holds the benchmark harness, and contrib/ holds packaging extras.

A debug build compiles in four commands and then needs a config edit

The debug path is four commands, and the step that makes it useful is manual and easy to miss.

The release route clones, creates a build directory, runs cmake with an explicit clang and an install prefix of /usr/local, then make and sudo make install.

git clone https://github.com/pgmoneta/pgmoneta.git
cd pgmoneta
mkdir build
cd build
cmake -DCMAKE_C_COMPILER=clang -DCMAKE_INSTALL_PREFIX=/usr/local ..
make
sudo make install

The debug route is the same shape with -DCMAKE_BUILD_TYPE=Debug and no install step. Only afterwards does the README say to remember to set the log_level configuration option to debug5.

A Debug compile flag and a debug5 log level are different things and neither enables the other. Without the config change you get a binary with symbols and nothing to say, which is the least useful combination of the two.

The release route also ends in a manual install under /usr/local rather than a package, so there is no uninstaller and no file manifest to reason about. The RPM route lands in the distribution's own paths and can be removed with the package manager. Two footprints with different upgrade habits, on the same project.

The RPM spec is checked into the repository root as pgmoneta.spec, and a separate document covers building one, so the packaging story exists even when you take the source route.

Two remote surfaces, a CLI and an MCP server

Remote control comes in two shapes, and the file never says how they differ.

One feature bullet names remote management through pgmoneta-cli or pgmoneta-mcp. Another, later in the same list, names an MCP server and client for interacting with the core using natural language. Reading the pairing, pgmoneta-mcp is the second bullet reached through the first, so the same remote surface is addressable from a command line and from a model.

The questions that follow are not answered. The TLS line specifies v1.2 or later for both client and server connections, and libssh is a required build dependency, which points at the transport used to reach a remote instance. Nothing in the visible text states which port the daemon listens on, what credential the CLI expects, or how the two surfaces differ in what they are allowed to do. For a tool that holds backup archives and database credentials, that gap is worth closing before you expose a daemon.

Offline detection of unreachable instances sits in the same feature list, so the daemon is built to survive a remote endpoint disappearing rather than blocking on it. That is the behaviour that matters most for something holding a chain of backups.

Four codecs, AES at rest, and no documented key handling

Compression and encryption are both offered as features rather than as options with documented behaviour.

Compression lists gzip, zstd, lz4, and bzip2. Nothing names a default or recommends one codec per backup type, so the choice happens in your configuration file rather than in the tool. Encryption is described as AES of backups at rest, with no mention of key generation, rotation, or an external key source. For a backup archive that may sit on shared storage for years, the key lifecycle is the part you want described, and it is not.

Credentials get their own treatment, at least in name. There is a user vault for managing PostgreSQL credentials securely, which is where the secrets pgmoneta needs to reach a cluster live. Nothing in the visible text ties that vault to the at-rest key, and nothing says what happens to an archive encrypted under a key that has since been rotated.

A worker pool for backup, restore, delete, and verify operations is also listed, which is the answer to how a large archive behaves when several of those run at once, stated in a single line with no configuration attached.

The newest tag is four and a half months behind the last push

The release cadence and the commit history have drifted apart.

The releases are 0.19.1 on 31 August 2025, 0.20.0 on 19 January 2026, and 0.21.0 on 29 April 2026. The last push to main is 14 September 2026, and the repository is not archived. So main has been moving for months past the current release, and the interval between tags has been running between three and five months.

That matters more here than it does for most projects, because the artefact you install is the one you rely on when something goes wrong. Building from source today gives you untagged work rather than the tested 0.21.0.

The documentation is pinned to the tag as well. The English and Spanish PDF links in the header point at assets attached to the 0.21.0 release, so a reader working on main is reading 0.21.0 documentation while running 0.21.0 plus whatever has landed since.

The rest of the repository looks like a settled systems project: a CMakeLists.txt at the root, cmake/, contrib/, doc/, src/, test/, and a benchmarks directory, plus AUTHORS, CODE_OF_CONDUCT.md, CONTRIBUTING.md, a .clang-format with a clang-format.sh driver, and pgmoneta.spec.

Editorial conclusion

pgmoneta is a good fit if you want backups without tying the toolchain to a PostgreSQL installation, if you run a modern PostgreSQL, and if you are willing to compile it unless you are on an EL 10 machine. Check four things before committing: which PostgreSQL version you are on, because tablespaces in an incremental chain need 17 or later; whether you can supply the AES key handling yourself, since none is documented; which tag you actually install, given that main has run ahead of 0.21.0 since April; and whether the remote surface you want is the CLI or the MCP server, since the README does not compare them.

Frequently asked questions

Official sources

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