Postgres Backup Tools in 2026: Read the Release Log First

For about three weeks last spring the most widely deployed PostgreSQL backup tool looked finished. David Steele, pgBackRest’s creator and effectively its only maintainer, announced on 27 April 2026 that he was stopping. Crunchy Data had paid for his time for years, the acquisition ended that, and no replacement showed up. Then on 18 May it un-ended, with a group of sponsors funding the work instead of one company.

The part worth checking is not the announcement. It is whether anything shipped afterward.

It did. pgBackRest released 2.59.0 on 20 July 2026 and 2.59.1 on 17 August, after 2.58.0 in January. The sponsor list on pgbackrest.org has grown from the six announced in May to nine: AWS, Supabase, pgEdge, Tiger Data, Percona, Eon, Xata, Dalibo, and Data Egret, with Crunchy Data and Resonate listed as past sponsors. So the answer to “should I migrate off pgBackRest” is no, and the migration a lot of people half-started in May was solving a problem that stopped existing.

What the scare was actually good for is that it made people ask a question they had not asked in years. Repository state below was read from the GitHub API and vendor documentation on 22 August 2026.

The release log answers the maintenance question in about a minute

Every project page says the project is healthy. The release history says whether that is true.

	Latest release	Released	Last push	Behind it
pgBackRest	2.59.1	17 Aug 2026	21 Aug 2026	Nine sponsors, second maintainer planned
WAL-G	v3.0.9	20 Aug 2026	21 Aug 2026	Community project, no single owner
Barman	3.19.1	27 May 2026	13 Aug 2026	EnterpriseDB
pg_probackup	2.5.16	9 Dec 2025	12 Jul 2026	Postgres Professional

Three of those four shipped something this quarter. The fourth is the one to look at closely, because pg_probackup gets described as actively maintained in most comparisons, including the earlier version of this one. Its release history says otherwise: 2.5.16 in December 2025 came after 2.5.15 in May 2024, which came after 2.5.13 in November 2023. That is three releases in roughly three years, on a tool whose entire job is to be correct about your data. The repository does get commits, so it is not abandoned. It is not on a cadence you can plan around either.

The vendor question that gets discussed more, that Postgres Professional is a Russian company and that raises sanctions and procurement questions for some organizations, is real but it is downstream of this one. If your procurement team clears it, the release cadence still has to.

Since PostgreSQL 17, the incremental is a server feature

The other thing that changed while nobody was looking is more interesting than the funding drama.

Incremental backup used to be entirely the tool’s problem. Each one invented its own way to work out which blocks had changed, and that machinery was most of what you were choosing between. PostgreSQL 17 added native incremental backup, where the server summarizes WAL and hands pg_basebackup the changed blocks directly. Barman’s block-level incremental is built on exactly that, which means it now depends on a Postgres version rather than on Barman’s own page tracking.

So the four tools no longer sit on one axis.

pgBackRest

Still the default I would pick without a specific reason to pick something else. Block-level incremental, parallel backup and restore across cores, lz4 and zstd compression, multiple repositories so you can write to local disk and to S3 in the same run, encryption at rest, and delta restore that fetches only the blocks that differ from what is already on disk. That last one is what makes rebuilding a replica against a multi-terabyte cluster finish in an evening instead of a weekend.

Two things to know before you upgrade rather than after. From 2.59.0, only the restore command may run as root by default, and everything else needs allow-root, which will break init scripts that were sloppy about the user. And 2.59.0 introduced a prebuilt distribution tarball that packagers are asked to use, so if you build from a GitHub source archive you may hit missing files, which 2.59.1 fixed.

The cost is the learning curve. Stanzas, repositories, and the archive command take an afternoon to click into place, and there is no way to skip that afternoon.

WAL-G

A single Go binary that pushes everything to object storage, which makes it the easy answer for Postgres in a container with S3 behind it. It handles S3, GCS, Azure Blob, and S3-compatible stores, and it covers a few non-Postgres databases if you run a mixed fleet.

Two details from the WAL-G documentation are worth reading before you trust your deltas. WALG_DELTA_MAX_STEPS defaults to 0, which means delta backup is off unless you turned it on, and plenty of installs are quietly taking full backups every night without anyone noticing the bandwidth. And delta backup only works when WAL-G runs on the database host and reads the data directory. Over the streaming BASE_BACKUP protocol, the mode that lets WAL-G run remotely as a separate user, the docs say delta backup “currently is not implemented.”

Neither is a defect. Both are things people assume the other way around.

Barman

Barman’s reputation is the centralized backup server for a fleet of on-premise databases, one host holding backups for many servers with barman list-backup giving you a single view. That part is still true, and the replication-slot handling and pg_receivewal streaming are the reason people who run estates like it.

The reputation that is now out of date is that it does not do cloud well. Barman 3.18 in March 2026 added block-level incremental backups written straight to cloud storage, streaming through a small staging area instead of landing the full backup on the Barman host. Barman 3.19 in May added restoring those backups back out of cloud storage, along with a cloud-wal-restore command you can use as Postgres’s restore_command. If you evaluated Barman more than a year ago and ruled it out on that basis, the basis has changed.

The catch is the PostgreSQL 17 requirement on the block-level path, plus summarize_wal enabled on the server before the first full backup. Rsync-based file-level incremental still works on older versions and stays self-contained, so it does not need a parent backup to restore.

pg_probackup

The most interesting incremental design of the four. Page-level tracking, and it can merge a previous full backup with its incrementals into a new synthetic full without reading the production server at all, which takes backup I/O off the live database.

I would still not start here in 2026, and the release table above is the reason rather than anything about the code. Add the smaller contributor base, which shows up as thinner search results the night something goes wrong, and the vendor questions that some organizations cannot get past, and it becomes a tool you adopt for a specific reason you can name, not a default.

If you are on RDS, Aurora, or Cloud SQL, none of this is yours

Worth saying plainly, because the April news reached a lot of people it did not apply to. Managed Postgres providers run physical backups and point-in-time recovery themselves. You cannot install pgBackRest on RDS and you should not try. The pgBackRest funding scare was gossip for managed users, not a risk.

This becomes your problem when you own the instance: bare metal, VMs, or Kubernetes with an operator. Some operators do use these tools underneath, so it is worth knowing which one yours ships with before you need to reason about a restore at three in the morning.

The thing to actually do this week

Run a restore. Not a check that the backup job exited zero. An actual restore into a throwaway instance, with point-in-time recovery to a specific timestamp, timed end to end, on the largest database you have.

The April scare got a lot of teams to audit which tool they run. Far fewer checked whether their restores work, and that is the check that fails. A backup you have never restored from is a hope with a cron entry attached.