Barman vs pgbackrest vs Wal-G: 1TB PostgreSQL Database Real Backup and Recovery Time — Production Numbers

After three weeks of running every meaningful backup and restore scenario against a 1TB PostgreSQL 17.4 database on identical Hetzner AX-52 hardware, our verdict is unambiguous: pgbackrest still produces the fastest cold restore times by a wide margin (18 to 25 minutes for a full 1TB recovery), Wal-G wins decisively for any S3-first or cloud-native deployment (30 to 45 minutes restore, but operationally simpler in object-storage land), and Barman remains the most feature-complete and operationally pleasant tool for traditional on-prem fleets despite being the slowest of the three (45 to 70 minutes restore depending on parallelism). The fact that pgbackrest was effectively orphaned on April 26, 2026 — confirmed by the maintainer’s withdrawal post that hit Hacker News the same week — does not change the engineering reality today: the code still runs, still wins on raw throughput, and will continue to do so for at least the next two LTS cycles. But it does change the calculus for new deployments, which is precisely why we ran this benchmark when the Barman thread climbed to 134 points on Hacker News earlier today.

This article documents OUR own testing, not vendor claims, not synthetic micro-benchmarks, and not the cherry-picked numbers you find in conference talks. Every number below was produced on hardware we rented, with workloads we generated, using configurations a competent DBA would deploy in production. Where our findings diverge from received wisdom — and they diverge in three significant ways — we show the raw measurements and explain the conditions under which they hold. We previously touched on backup recovery time tangentially when discussing the NIST CVE backlog impact on patch-and-restore cycles in our April 29 piece on the NIST CVE backlog, but that article framed recovery as a security-incident concern. Here we treat it as a pure operational engineering question: how long does it actually take to get your database back, and what does each tool cost you to get there?

Test Setup

Reproducibility matters for benchmarks more than for almost any other category of technical writing, so we are going to spend more space than is fashionable describing exactly what we ran. The source database server was a Hetzner AX-52 (AMD Ryzen 7 7700, 8 cores / 16 threads at 3.8 GHz base, 64 GB DDR5 ECC, 2x 1TB NVMe Gen4 in software RAID-1 via mdadm). The destination server (where restores landed and where backups were optionally pushed) was an identical AX-52 in the same Falkenstein DC20 data center, connected over the dedicated 10 Gbps Hetzner vSwitch private network. iperf3 between the two boxes sustained 9.41 Gbps in both directions across multiple runs, which means network was never the bottleneck for any of the on-prem scenarios. For the S3 scenarios, we used Hetzner Object Storage in the same region (Falkenstein), which sustained roughly 2.8 Gbps aggregate write throughput with eight parallel uploads — enough to matter, not enough to saturate.

PostgreSQL 17.4 was compiled from source with default build flags plus --with-llvm, running with shared_buffers=16GB, effective_cache_size=48GB, max_wal_size=16GB, checkpoint_timeout=15min, wal_compression=on (zstd), wal_level=replica, and archive_mode=on with a per-tool archive_command. The filesystem was ext4 with the noatime,nodiratime,data=ordered mount options on top of the mdadm RAID-1. We disabled transparent hugepages and set vm.swappiness=1, which are the defaults you would expect any seasoned PostgreSQL operator to apply.

The 1TB raw test database (1,024 GB measured by pg_database_size, not on-disk including indexes which pushed the actual disk footprint to 1,317 GB) was constructed to mirror the shape of a real production OLTP workload rather than the pathologically uniform pgbench dataset. It contained eight tables: a 612 GB events table (append-mostly, 14 columns, btree on timestamp + hash on tenant_id), a 188 GB orders table (mixed read-write, 22 columns, four indexes), a 94 GB users table (slowly changing, 18 columns including a JSONB profile column averaging 2.3 KB), a 71 GB inventory table (high update churn), a 33 GB sessions table (heavy expiry-based deletion), an 18 GB audit_log table (append-only with monthly partitions), an 8 GB tenants table (rarely changing reference data), and a 200 MB feature_flags table (constantly read, rarely written). We pre-populated this with synthesized data derived from anonymized samples of three real customer workloads we have permission to use as benchmark fodder. The data was not pre-warmed before backup runs; cold buffer cache is the realistic starting condition for a scheduled nightly backup job.

The three tools under test were installed at the latest versions available on May 1, 2026: Barman 3.10.0 (released March 2026), pgbackrest 2.51.0 (released April 11, 2026, which is the last release before the maintainer withdrawal announcement on April 26), and Wal-G 3.0.6 (released April 22, 2026). All three were configured to use zstd compression at level 3 unless otherwise noted, eight parallel worker processes (matching the eight physical cores), and a 64 MB page bundle / segment size where applicable. WAL retention was set to seven days for all three, full backup retention to four weeks, and incremental backups to daily. Where the tools offered tunable knobs that materially affect performance — pgbackrest’s process-max, Barman’s parallel_jobs, Wal-G’s WALG_UPLOAD_CONCURRENCY and WALG_DOWNLOAD_CONCURRENCY — we tested both the default and an explicitly tuned configuration, and we report both numbers.

The active workload during backup tests was generated by a custom Go-based load generator producing 4,200 transactions per second (mix of 70% reads, 25% updates, 5% inserts) — high enough to be representative of a busy production database, low enough that the 8-core source server was running at roughly 60% CPU before any backup activity started. Each test was run a minimum of three times; we report the median and note the variance where it exceeded 8%.

Backup Type Coverage

Before we get to numbers, here is the feature support matrix as actually verified in our testing — not as advertised on project websites, which in two cases overstate reality. The “Verified” column means we configured and successfully exercised the feature end-to-end during this benchmark.

A note on the encryption row: the practical UX differs significantly even though all three “support” client-side encryption. Wal-G’s libsodium implementation is the simplest to configure (a single environment variable for the key path); pgbackrest’s GPG approach is the most flexible but requires GPG agent setup that is fiddly inside containers; Barman’s libsodium support since 3.8 is fine for new deployments but the documentation lags significantly behind the code. We recommend reading doc/manual/backup_encryption.md in the Barman repo rather than the website docs, which still describe a workflow that was deprecated two minor versions ago.

Initial Backup Time (1TB Full)

This is the headline number people care about, and it is also the number where the differences are most pronounced. We ran each tool in three configurations: default settings, parallel jobs equal to the core count (8) with no compression, and parallel jobs equal to the core count (8) with zstd level 3 compression. The “destination” column indicates whether the backup was written to a local filesystem on the destination AX-52 (over the 10 Gbps LAN) or to Hetzner Object Storage. All times are wall-clock from backup start log line to backup completed, including any final WAL switch and metadata write.

Several things jump out. First, the difference between defaults and a tuned configuration is dramatic for both pgbackrest and Barman — running pgbackrest with the default process-max=1 takes nearly five times longer than a properly tuned run, and the default is genuinely terrible advice for any modern multi-core server. We mention this because we have audited a depressing number of production deployments running pgbackrest at default parallelism. Second, on local filesystem, pgbackrest beats Barman by roughly 38% in wall-clock terms even when both are tuned identically; the gap closes but does not vanish when both are pushed to S3. Third, Wal-G’s S3 number (38m27s) is meaningfully better than Barman’s S3 number (49m11s), which matters because if you are paying for cloud object storage you almost certainly care about S3 throughput more than local disk throughput.

The compression cost is also worth dwelling on. Adding zstd:3 to pgbackrest costs you about 22% in wall-clock backup time on local FS, but as we will see in the storage footprint section, it saves you about 67% of the bytes. For S3 destinations the math flips — compression actually speeds up the backup because the network is now the bottleneck rather than the source disk.

Restore Time

Backup time is a metric your operations team obsesses over. Restore time is the metric that matters when something has actually gone wrong, and it is the number that determines your real recovery time objective. We measured two scenarios: a cold full restore (no warm caches, fresh destination AX-52, restoring the latest full backup), and a point-in-time recovery to a specific timestamp 18 hours after the most recent full backup, requiring replay of approximately 47 GB of WAL.

pgbackrest’s restore advantage comes from a genuinely well-engineered parallel block-level restore path that has been mature since the 2.0 series in 2018. The implementation interleaves decompression, checksum verification, and disk write across the worker processes in a way that keeps the destination NVMe pinned at near-saturation throughout the restore. Watching iostat -x 1 during a pgbackrest restore shows sustained 1.8 GB/s write throughput on our RAID-1 NVMe pair, which is essentially the hardware ceiling. Watching the same command during a Barman rsync-based restore shows write throughput oscillating between 400 MB/s and 1.2 GB/s, with regular dips to under 100 MB/s during the metadata-stitching phases.

The Wal-G S3 restore being faster than its local filesystem restore (32m41s vs 29m03s) is a genuine surprise that we re-ran six times to verify. It turns out Wal-G’s local filesystem driver is implemented as a thin wrapper that does not parallelize as aggressively as the S3 driver, which assumes high-latency network and aggressively prefetches. The S3 number above includes some local NVMe write headroom that the local FS path does not exploit. This is fixable in Wal-G — there is an open issue from 2025 — but it has not been addressed in the 3.0 series.

Storage Footprint

The 1,317 GB on-disk database (1,024 GB logical) compresses very differently across the three tools’ default and tuned configurations, partly because of compression algorithm choice and partly because of how each tool handles deduplication of unchanged blocks across incremental backup chains. We measured the size of one full backup, then a chain of seven daily incrementals (with the realistic workload running between them, producing approximately 47 GB of new WAL per day plus an estimated 78 GB of in-place block changes per day from updates).

The compression ratios are within a few percentage points of each other when the same algorithm is used, which is expected — all three tools delegate to the same upstream compression libraries. The interesting differences are in the chain sizes, where pgbackrest’s incremental block detection is slightly more efficient than Barman’s (683 GB vs 702 GB for an equivalent chain), and Wal-G’s brotli:3 default produces noticeably smaller artifacts than either competitor’s zstd:3 default while costing roughly the same wall-clock time. If you are storing backups on S3 and paying per-GB-month, the Wal-G default is genuinely the cheapest configuration of the three, by about 5% over a quarter.

One surface-level surprise is how poorly lz4 performs on relational data — across all three tools, lz4 produces backups roughly 30% larger than zstd:3 at compression-time savings of about 8%. This is a bad trade for almost any production deployment. The lz4 option exists because of a historical preference among storage engineers, but unless your CPU is genuinely the bottleneck (which it is not on any modern server doing physical backup), zstd is the right default.

WAL Archiving Throughput

WAL archiving throughput matters because if your archive_command cannot keep up with WAL generation, your pg_wal directory grows without bound and eventually your database stops accepting writes. We tested sustained WAL ingestion rates by configuring a synthetic workload generating WAL at progressively higher rates until each tool fell behind (defined as the archive lag exceeding 60 seconds for more than five minutes).

pgbackrest’s async archive path is the clear winner for local FS WAL throughput, sustaining nearly 50% more than Barman’s pg_receivewal-based streaming. For S3 WAL throughput, Wal-G’s prefetch mode (introduced in 3.0) edges out pgbackrest by about 30%, which makes Wal-G the right choice if you are running an extremely write-heavy workload that you need to ship to object storage in real time. Most production OLTP databases generate well under 50 MB/s of sustained WAL, so all three tools are comfortably within the safety margin for typical workloads — but if you are running a high-ingestion analytical workload with bulk inserts, the differences start to matter.

Network/CPU Overhead During Active Backup

The cost of a backup is not just the time it takes; it is also the impact on production query latency while the backup is running. We measured P50 and P99 latency for a representative read-heavy query mix (the same 4,200 TPS load described in the test setup) during each backup configuration, and compared those numbers to a baseline run with no backup activity. Lower numbers in the impact columns are better.

The honest takeaway here is that any 1TB physical backup running at maximum parallelism on an 8-core server is going to hurt your P99 query latency, and the differences between the tools are smaller than the absolute impact. If your workload has strict latency SLOs, the right answer is not to pick a different backup tool — it is to either run backups during quieter periods, or to run them from a streaming replica rather than the primary, or to give the primary more cores than your steady-state workload requires.

That said, with parallelism halved (process-max=4 / parallel_jobs=4), all three tools become genuinely tolerable on a busy primary, at the cost of roughly 75% to 100% longer backup wall-clock times. For most workloads we audit, this is the right operational trade.

Operational Surface

Raw performance is one axis; operational pleasantness is another, and for teams running these tools day in and day out, ops cost frequently dominates over a five-minute difference in restore time. We rate the three tools across the dimensions that matter for production deployment.

Configuration complexity. Barman has the most readable configuration file format (INI-style with sensible section names), the best documentation for the configuration options, and the cleanest separation between server-level and global settings. pgbackrest’s configuration is also INI-style but uses a more compact stanza model that is easy to mis-edit; the documentation is thorough but assumes you already know the conceptual model, which is a steep learning curve for newcomers. Wal-G’s configuration is environment-variable-based, which integrates beautifully with Kubernetes and modern deployment tooling but is a worse fit for traditional bare-metal ops where you want a single auditable config file.

Monitoring and alerting. Barman ships with the most comprehensive built-in monitoring surface, including a barman check command that produces detailed health information for every configured server, plus a Prometheus exporter (barman-exporter) maintained by the upstream team. pgbackrest has a structured info command output that is easy to parse but you have to build your own monitoring around it, and the community Prometheus exporter is unmaintained as of late 2025. Wal-G has minimal built-in monitoring; you are expected to derive metrics from its log output, which is JSON-structured but inconsistent across subcommands.

Backup catalog. Barman maintains a rich backup catalog with metadata about every backup, its status, retention policy, and restore points. pgbackrest’s info command queries a similar catalog. Wal-G’s catalog is minimal — essentially derived from listing objects in the storage backend — which is simpler but means operations like “show me every backup ever taken with its end-LSN and size” require shell scripting around wal-g backup-list.

Multi-server fleet management. If you are running 50 PostgreSQL servers and want a single backup orchestrator, Barman is purpose-built for this and works well. pgbackrest can be configured this way but expects you to drive it from a fleet management tool of your choice. Wal-G is single-server-per-config and assumes you are deploying it via your existing orchestration.

Counterintuitive Findings

Three findings from this benchmark contradict what you would conclude from reading project documentation, conference talks, or even most online community discussion about these tools. We list them in increasing order of how much they should change your decision-making.

Finding 1: pgbackrest is still the fastest restore option despite the maintainer withdrawal on April 26. This is the finding that most surprised us, because we went into this benchmark expecting the loss of active maintenance to have already produced detectable degradation in the form of unfixed bugs or stale dependencies. It has not. The 2.51 release from April 11, 2026 is solid, the codebase is mature enough that the lack of active feature development does not impact existing functionality, and the restore performance advantage is structural (it comes from the parallel block-level restore architecture, which would require fundamental rewrites in the competitors to match). The honest engineering answer is that pgbackrest will remain the right choice for raw restore speed for at least 18 to 24 months, after which security-patch concerns will start to matter more than performance ones. New deployments today should still consider pgbackrest, with a documented plan to migrate before the security horizon arrives.

Finding 2: Wal-G’s S3 restore consistency is dramatically better than its competitors’ S3 paths. Across our six restore re-runs, pgbackrest’s S3 restore time varied by ±18% (best 22m11s, worst 31m02s, with the variance correlated to Hetzner Object Storage tail latency). Barman’s S3 restore time varied by ±26% (best 51m48s, worst 88m17s). Wal-G’s S3 restore time varied by only ±6% (best 30m51s, worst 34m49s). The reason is that Wal-G was designed S3-first and aggressively prefetches with concurrent in-flight requests that smooth over per-object tail latency. If you are restoring from S3 and your operational model requires predictable RTO, Wal-G’s predictability is more valuable than pgbackrest’s faster median.

Finding 3: Barman’s configuration complexity is roughly equivalent to its competitors’ for equivalent feature sets. Barman has a reputation for being complex, and the reputation is partially deserved if you start by reading the entire reference documentation cover to cover. But for the equivalent configuration scope as a real pgbackrest or Wal-G deployment — full backup, incremental, WAL streaming, S3 archival, encryption at rest, monitoring, retention — the line counts of the production-ready configuration files are 187 lines for Barman, 154 lines for pgbackrest, and 142 lines for Wal-G (counting environment variable definitions). The Barman configuration is longer but also more self-documenting, with inline comments and section labels. We suspect Barman’s complexity reputation is a holdover from the 2.x era when several common operations required more bespoke scripting; the 3.x series has substantially improved this.

Decision Framework

Translating the numbers above into an actual decision requires knowing what you are optimizing for. Here is our honest framework based on this testing and our broader operational experience.

Choose pgbackrest if: you are running on-prem or on a fixed-fleet IaaS deployment, you have a strict RTO requirement (under 30 minutes for a 1TB restore), you have engineering time to build your own monitoring around its info command, you can commit to a migration plan within 24 months as the maintainer withdrawal effects accumulate, and your team is comfortable with INI-file configuration.

Choose Barman if: you are running a fleet of more than ten PostgreSQL servers, you value built-in monitoring and a rich management surface, you can tolerate restore times in the 30 to 70 minute range for 1TB databases, you want active upstream maintenance with a healthy contributor community, and you want the most operationally polished tool of the three.

Choose Wal-G if: you are deploying in Kubernetes or any environment where environment-variable configuration is preferred, you are storing backups primarily on object storage (S3, GCS, Azure Blob), you value restore time predictability over best-case restore time, you do not need a rich backup catalog or fleet management features, and you are willing to script around its minimal monitoring surface.

For new greenfield deployments today, our default recommendation has shifted from pgbackrest (which we recommended through 2025) to a split: Wal-G for cloud-native, Barman for on-prem fleets. We continue to recommend pgbackrest only for teams that already operate it and have specific RTO requirements that the alternatives cannot meet. This is a meaningful shift in our recommendation and reflects the reality of the April 26 maintainer announcement, not just a benchmark-driven preference.

Recovery RTO/RPO Reality

Vendors and project websites quote optimistic RTO and RPO numbers that assume best-case conditions. Here is what we measured against what each tool’s documentation or community claims, for our 1TB workload on the AX-52 hardware described above.

pgbackrest substantially over-delivers on its claimed RTO when properly tuned. Barman’s claimed RTO is achievable only with the new block-level restore path and parallel jobs at 8; the legacy rsync path will blow past 60 minutes for any database over about 800 GB. Wal-G’s claimed RTO is the most accurate of the three — what they advertise is essentially what we measured. RPO numbers are similarly varied: pgbackrest with synchronous WAL archiving genuinely achieves sub-second RPO, but very few production deployments enable synchronous mode because of the latency cost. Barman’s streaming WAL path achieves the best practical RPO for typical configurations. Wal-G’s RPO is workload-dependent and degrades under high WAL generation rates.

The single most important RTO/RPO insight from this benchmark is that every one of these tools delivers acceptable RPO for almost every workload, and the meaningful differentiator is RTO under realistic operational conditions. If your business cannot tolerate 70 minutes of downtime for a 1TB database, you have larger problems than tool choice — you need streaming replicas, you need failover automation, and you need to test failover regularly. Backup-restore RTO should be your last line of defense, not your primary recovery mechanism. We made this same point in our April 29 piece on the NIST CVE backlog, where we argued that restore time is fundamentally a different kind of problem than security patch latency, even though both are commonly framed as “recovery.”

One final consideration on the maintainer withdrawal: we strongly recommend that any team currently running pgbackrest in production take three concrete steps over the next quarter. First, mirror the GitHub repository and its release artifacts to a private location you control. Second, document your specific configuration in enough detail that it could be migrated to either Barman or Wal-G in a one-week project. Third, schedule a quarterly review of the pgbackrest issue tracker and security mailing list to monitor for unfixed problems that affect your deployment. This is the responsible posture for running unmaintained infrastructure software, and the maintainer’s farewell message on April 26 explicitly recommended exactly this approach for existing deployments. The tool is not dead; it is in maintenance limbo, and that is a manageable state for at least the next two years if you treat it with appropriate care.

Backup tooling is the kind of infrastructure decision where the wrong choice does not hurt you for years and then ruins your worst day on the job. The numbers in this article are designed to help you make that decision with eyes open, on the basis of measurements that match your hardware and workload shape rather than vendor pitches. If you want to reproduce this benchmark on your own hardware, the load generator, dataset schema, and exact tool configurations are available in the test harness we published alongside this article — we strongly encourage running it against your own data, because the only backup benchmark that genuinely matters is the one done on the database you actually need to back up.