Barman vs pgBackRest: a decision tree for PostgreSQL backup in production

There's a question that surfaces every time someone grows with PostgreSQL without a dedicated DBA: what tool do I use for backup? The community has already pushed pgBackRest as the "modern" answer. Barman has spent years as the "enterprise" pick. I have something to say about this — but it's not picking a winner. It's explaining why the question, badly framed, leads you straight to the wrong decision.

My thesis: there's no universal winner between Barman and pgBackRest. Barman wins when you need simplicity and real-time WAL streaming with low operational overhead. pgBackRest wins when volume grows, you need parallel incremental backup, and fast restore on large databases. The criteria — RTO, RPO, deploy environment, and DB size — matter more than any generic recommendation.

None of this is in the official docs. It's the friction that shows up when you have to decide without being a DBA and without anyone drawing you the decision tree.

What each tool says about itself (and what it doesn't)

Before any decision, you have to read the sources without romanticizing them.

Barman (pgbarman.org) is a backup and recovery tool for PostgreSQL developed and maintained by EnterpriseDB. The official documentation describes support for real-time WAL streaming via pg_receivewal, base backup, backup catalog, and point-in-time recovery (PITR). The configuration model is declarative: one barman.conf file per server. It connects to the primary server and can manage multiple instances from a centralized Barman server.

What Barman's documentation doesn't say explicitly: how long a restore actually takes on multi-terabyte databases. That depends on your hardware, your network, and whether you have compression active or not.

pgBackRest (pgbackrest.org) presents a broader feature set: full, differential, and incremental backup, configurable parallelism in both backup and restore, compression with multiple algorithms (gzip, lz4, zstd), encryption, and support for S3/GCS/Azure storage in addition to local. The official documentation includes extensive configuration guides and an info command that shows the state of all cataloged backups.

What pgBackRest's documentation doesn't say explicitly: the initial configuration curve is noticeably steeper than Barman's. A first working setup requires correctly configuring repos, stanzas, SSH authentication or cloud storage permissions, and the pgbackrest.conf file on the database server. It's not hard, but it's not trivial either on a VPS with your own root access and no runbook.

None of this is a design flaw. It's the honest trade-off between two tools with different priorities.

Decision tree: when to pick each one

Before choosing, there are four variables that matter. If you answer them honestly, the decision almost makes itself.

Variable 1: Database size

For databases that fit comfortably in tens of gigabytes, full backup time isn't the bottleneck. Barman works well in that range with its base backup + WAL archiving model.

For databases growing into hundreds of gigabytes or more, full backup starts becoming an operational problem. pgBackRest with incremental backup and configurable parallelism (--process-max) changes the equation: instead of copying everything every time, it copies only the blocks modified since the last differential or incremental. The official pgBackRest documentation describes this behavior in detail in the backup types section.

Variable 2: Required RPO (how much data can you afford to lose?)

If RPO is strict — say, seconds or minutes — you need real-time WAL archiving or WAL streaming. Barman supports pg_receivewal for real-time WAL streaming according to its official documentation. pgBackRest also supports WAL archiving, though real-time streaming isn't its central marketing feature.

If RPO can be hours (a daily backup is enough), either tool solves the problem.

Variable 3: Required RTO (how long can you afford to spend restoring?)

This is where pgBackRest has a documented advantage: parallelism on restore. If you have a machine with multiple CPUs available during the restore, pgBackRest can use several simultaneous processes to decompress and copy files. Barman restores serially by default.

For applications where restore time is critical and the database is large, this is not a minor detail.

Variable 4: Deploy environment

The Railway row isn't accidental. In PaaS environments where you don't have direct access to the PostgreSQL server's filesystem, and can't run auxiliary processes like pg_receivewal or the pgBackRest agent, neither Barman nor pgBackRest installs in any standard way. The typical approach in those environments is a periodic pg_dump to an S3 bucket, with a script or external job. Not elegant, but it's what the environment allows.

Where people go wrong (and the hidden cost)

The most common mistake is treating backup as an installation decision, not an operational one. You install Barman or pgBackRest, run a first backup, check that the directory has files, and assume the problem is solved.

The hidden cost shows up later:

1. Nobody tests the restore. An untested backup is theory. The only way to validate that a backup is actually useful is to run a restore in a test environment and verify the database comes up with consistent data. No tool can do that for you automatically — it's an operational decision that requires a periodic process.

2. WAL archiving silently fails. Barman can be running, the pg_receivewal process can be active, and the WAL streaming can still break without any visible alert if nobody's monitoring the lag between the last WAL received and the current WAL on the primary. barman check <server> returns the state of all configured checks — you have to run that, not assume it.

3. pgBackRest misconfigured for parallelism can saturate the server during backup. The --process-max parameter controls how many parallel processes pgBackRest uses. On a server with an active workload, bumping that number without measuring the impact can degrade the database during backup. The official documentation lists it as a configurable variable without giving a universal value — because there isn't one.

4. Retention doesn't configure itself. If you don't set an explicit retention policy in Barman (retention policy) or pgBackRest (repo1-retention-full), the backup directory grows indefinitely. This is in the official documentation for both tools — it's not an opinion.

Decision checklist before you choose

Answer these questions before installing anything:

Decision checklist: Barman vs pgBackRest

Answer honestly — there are no wrong answers

• ✓ Is the database over 100 GB in production? YES → pgBackRest (incremental + parallelism) NO → Barman or pgBackRest, based on preference

• ✓ Do you need RPO of minutes or less? YES → Barman with pg_receivewal OR pgBackRest with WAL archiving configured NO → pg_dump + cron might be enough

• ✓ Do you need RTO under 1 hour on a large database? YES → pgBackRest (documented parallel restore) NO → Barman is viable

• ✓ Do you manage multiple PostgreSQL instances? YES → Barman (native centralized multi-server management) NO → Either one works

• ✓ Is the environment PaaS (Railway, Render, Heroku)? YES → Neither directly; evaluate pg_dump + S3 with an external job NO → Keep going through the tree

• ✓ Do you have access to S3 or compatible cloud storage? YES → pgBackRest has documented native support for S3/GCS/Azure NO → Barman with local storage or NFS

• ✓ Is this the team's first serious backup setup? YES → Barman has less initial configuration surface area NO → pgBackRest if there's already experience with repos and stanzas

• ✓ Is there a defined restore testing process? YES → Either works if the process exists NO → Start there before picking a tool

Limits of this analysis

There are things this post can't conclude without your own experiments or production data:

• I can't tell you how long a restore takes on your hardware. That depends on the disk, the network, the amount of accumulated WAL, and the size of the base data. The only way to know is to measure in an environment that resembles production.

• I can't tell you which one uses less CPU or RAM under mixed load. Both tools have configurable parameters that affect the impact on the primary server. Without my own production logs, any number I cited here would be made up.

• I can't tell you which one "is more reliable." Both have years of production use, active documentation, and real communities. Operational reliability depends on configuration, monitoring, and restore practice — not on the tool.

If you need to validate a decision with your own data, the reproducible experiment is clear: install the tool in a staging environment with an anonymized production dump, run a backup, measure the time, run a restore, measure the time, and make the decision with those numbers. Not with anyone else's.

FAQ

Can I use Barman or pgBackRest on Railway?

On Railway, access to the PostgreSQL server's filesystem and the ability to run auxiliary processes like pg_receivewal or the pgBackRest agent are limited by the PaaS model. The most pragmatic approach in those environments is a periodic pg_dump to an S3 bucket using an external job or a separate container. It's not the same as real-time WAL archiving, but it's reproducible and auditable.

Does Barman need a dedicated server?

It's not mandatory, but Barman's official documentation assumes a Barman server separate from the PostgreSQL server. On a small VPS, it's possible to run them on the same machine — but that eliminates protection against hardware failure on the primary. If the backup and the database live on the same disk, a disk failure kills both.

Can pgBackRest do incremental backup from day one?

Not directly. pgBackRest requires a full backup as a starting point before it can run diff or incr backups. The official documentation describes this explicitly: without a prior full backup in the stanza, the first backup is always full regardless of the type you specify.

What happens if I don't configure retention?

In Barman, if you don't configure a retention policy, backups accumulate indefinitely and available space eventually runs out. In pgBackRest, if you don't configure repo1-retention-full, the default behavior retains a limited number of full backups — but the associated WAL can still pile up. Check the official documentation for each tool before assuming the defaults are safe.

Can I migrate from pg_dump to Barman or pgBackRest without downtime?

The migration doesn't require database downtime. Barman and pgBackRest are configured in parallel and start taking backups without interrupting the service. What it does require is a validation window: run the first full backup, verify the catalog, and test a restore in staging before retiring the old pg_dump process.

Is pgBackRest harder to configure than Barman?

In terms of initial configuration, yes. pgBackRest requires defining stanzas, configuring repos (local, S3, or cloud), and making sure the pgbackrest.conf file is correctly placed on both the database server and the backup server. Barman has a more linear configuration model. The extra complexity in pgBackRest comes with extra features — it's not gratuitous complexity.

Closing: criteria before tools

When I work with PostgreSQL via Prisma without a dedicated DBA, the question I ask myself isn't "what's the best backup tool?" — it's "what do I need to prove works before something breaks in production?" Those two questions lead to very different answers.

My position after going through both tools with their official documentation: if the team is setting up serious backup for the first time, Barman has less initial surface area and the real-time WAL streaming is well documented. If the database has already grown and restore time is starting to be a measurable problem, pgBackRest has the tools to attack it — but you have to invest in the setup.

What I don't buy is the version where one tool "always wins." That's usually someone who found what worked for them at scale X and generalized it without looking at the context. The criteria — RTO, RPO, environment, size — matter more than any generic recommendation.

And before picking either one: define how you're going to test the restore. Without that, your backup is nice documentation you never actually read.

If you're interested in the infrastructure and diagnostics tooling ecosystem, I also wrote about how to monitor your network without losing your mind with tcpdump and about rate limiting in web applications: what to protect before picking a library. And if you work with Next.js and PostgreSQL together, the post on App Router caching has decisions that apply directly to the stack.

Original sources:

• Barman — official documentation: https://pgbarman.org/
• pgBackRest — official documentation: https://pgbackrest.org/