# pgBackRest vs Barman vs WAL-G Compared [2026] > pgBackRest nearly died in April 2026 when its sole sponsor pulled out. Here's what happened, who rescued it, and how it compares to Barman and WAL-G for production PostgreSQL backups. - Canonical: https://www.kunalganglani.com/blog/postgresql-backup-tools-compared - Author: Kunal Ganglani - Published: 2026-04-27 · Updated: 2026-07-11 - Category: Technology · Tags: postgresql, database-backup, pgbackrest, barman, wal-g, devops, database-administration, open-source ## TL;DR pgBackRest, the most popular PostgreSQL backup tool, was nearly abandoned in April 2026 when its only sponsor pulled funding. A coalition of six companies rescued it three weeks later, but the scare forced every DBA to reconsider their backup strategy. pgBackRest still wins on backup granularity and performance, Barman is best for enterprise fleet management with zero data loss guarantees, and WAL-G is the simplest option for cloud-native teams running multiple databases. Your choice depends on your RPO/RTO requirements, team size, and infrastructure type. ## pgBackRest vs Barman vs WAL-G Compared [2026] pgBackRest is the most widely deployed physical backup tool for production PostgreSQL databases, used by thousands of organizations to protect terabytes of critical data. On April 27, 2026, its sole maintainer [David Steele](https://pgbackrest.org/news.html) announced it was no longer being maintained — and the PostgreSQL community went into full panic mode. Twenty-one days later, a coalition of six sponsors rescued the project. But the damage was done: every production DBA running pgBackRest suddenly had to ask whether they should stay, switch to Barman, or migrate to WAL-G. ![a computer screen with a lot of text on it](https://cdn.sanity.io/images/vzekdneq/production/82c000f2af89604aedb9acbff58783a36ae7846b-1200x675.webp) **Key takeaways:** - pgBackRest was rescued on May 18, 2026 by AWS, Supabase, Percona, pgEdge, Tiger Data, and Eon.io — ending its dependence on a single sponsor (Crunchy Data) and arguably making it more sustainable than before. - Barman (maintained by EnterpriseDB) is the only tool that achieves RPO=0 via synchronous streaming replication and manages multiple PostgreSQL servers from a single centralized location. - WAL-G (originally created by Yandex, now community-maintained) is the cloud-native option — it pushes backups directly to S3/GCS/Azure with 16 concurrent upload streams by default and requires no dedicated backup server. - For most production teams, pgBackRest remains the best general-purpose choice. Barman wins for enterprise fleet management. WAL-G wins for cloud-native, multi-database environments. - pg_dump is not a backup strategy at scale — it's a logical export tool that cannot provide point-in-time recovery or handle multi-terabyte databases efficiently. > Physical backup tools don't just save your data — they save your job when the 3 AM page comes in. ## What Happened: The pgBackRest Maintenance Crisis of April 2026 On April 27, 2026, [David Steele](https://pgbackrest.org/news.html), the sole maintainer of pgBackRest, posted a brief and devastating announcement: pgBackRest was "No Longer Being Maintained." The immediate cause was the end of Crunchy Data's sponsorship — Crunchy had been the project's only financial backer. ![black flat screen computer monitor](https://cdn.sanity.io/images/vzekdneq/production/099614c88f6c6917dbde4fa5669263c5c1cb1305-1200x675.webp) This wasn't a theoretical open-source sustainability problem. pgBackRest is the default backup tool recommended by most PostgreSQL consultancies and cloud providers. It handles parallel backup and restore, block-level incremental backups, multi-repository support, and lz4/zstd compression. Thousands of production databases depend on it. When the announcement dropped, PostgreSQL Slack channels and mailing lists lit up with a single question: "What do we do now?" A maintenance update followed on May 7, buying time but not resolving the underlying funding gap. Then, on May 18, 2026 — exactly 21 days after the initial announcement — Steele posted the resolution. Six organizations had formed a sponsorship coalition: Amazon Web Services, Supabase, pgEdge, Tiger Data (the creators of TimescaleDB), Percona, and Eon.io. As [David Steele](https://pgbackrest.org/news.html) wrote: *"Their support means the project is no longer reliant on a single sponsor, giving pgBackRest the stability it needs for the long term."* This is the part that matters for your backup strategy: pgBackRest went from single-sponsor fragility to a diversified funding model in three weeks. That's actually a better position than it was in before the crisis. But the episode exposed a structural risk that every production DBA should factor into their tooling decisions. I've written about [open-source sustainability crises](/blog/open-source-sustainability-crisis) before — the pgBackRest situation follows the same pattern as Redis and HashiCorp. A critical piece of infrastructure maintained by one person, funded by one company, with the entire ecosystem assuming it will just keep working forever. ## pgBackRest Compared to Barman and WAL-G: Is It Still Safe? Yes. pgBackRest is not only still maintained — it's arguably on more stable footing than it was six months ago. The shift from a single sponsor (Crunchy Data) to six sponsors (AWS, Supabase, Percona, pgEdge, Tiger Data, Eon.io) reduces the bus factor significantly. If one sponsor drops out, five others remain. ![Code written on a screen, likely programming related.](https://cdn.sanity.io/images/vzekdneq/production/f47c157330fb0563fa0a1484945cf00266e87b92-1200x675.webp) But "still maintained" and "the right choice for your team" are different questions. The April 2026 scare was a wake-up call. If you haven't evaluated alternatives recently, now is the time. Here's how the three major PostgreSQL physical backup tools stack up. ## pgBackRest: Features, Strengths, and Status (v2.58.0) pgBackRest v2.58.0, released January 19, 2026, is the current stable version. Written in C for raw performance, it's the most feature-rich backup tool in the PostgreSQL ecosystem. **What makes pgBackRest the default choice:** - **Block-level incremental backups** — pgBackRest doesn't just track which files changed. It tracks which blocks within files changed. For large databases where only a small percentage of data changes between backups, this dramatically reduces backup size and time. Neither Barman nor WAL-G matches this granularity. - **Parallel backup and restore** — multiple threads for compression, checksumming, and transfer. On a 2TB database, this is the difference between a 4-hour restore and a 45-minute restore. - **Multi-repository support** — back up to local disk AND S3 AND GCS simultaneously. Redundancy without scripting. - **Full, differential, and incremental backup types** — giving you flexibility to balance storage costs against restore speed. - **Cloud storage support** — v2.58.0 added HTTP support for S3, GCS, and Azure, plus Azure managed identities and experimental S3 EKS pod identity. - **TLS and SSH remote operation** — back up remote servers without installing the full tool on each database host. **The catch:** pgBackRest is PostgreSQL-only. If you also run MySQL, MongoDB, or Redis, you need a separate backup tool for each. Configuration is more involved than WAL-G — there's a dedicated configuration file with many options, which is powerful but has a learning curve. pgBackRest has roughly 4,200 GitHub stars and 380 forks, with an active release cadence maintained primarily by David Steele with community contributions. ## Barman: EnterpriseDB's Battle-Tested Backup Manager Barman (Backup and Recovery Manager) version 3.19.1 was released May 26, 2026 — just days after the pgBackRest rescue announcement. It's maintained by [EnterpriseDB](https://www.enterprisedb.com/docs/supported-open-source/barman/) (EDB), which provides commercial support, making it the only tool in this comparison with a dedicated enterprise backing. **Where Barman stands out:** - **RPO=0 via synchronous streaming replication** — Barman can achieve zero data loss through a synchronous physical streaming replication connection. If your business requires an RPO of zero — meaning you cannot lose a single transaction — Barman is the only tool here that offers that guarantee out of the box. - **Centralized multi-server management** — Barman manages backups for multiple PostgreSQL servers from a single dedicated backup server. For teams running 10, 50, or 200 PostgreSQL instances, this centralized model is a massive operational advantage over pgBackRest's per-server approach. - **Backup catalog and retention policies** — list, keep, delete, archive, and recover multiple backups through a clean catalog interface. - **WAL archive compression** — supports gzip, bzip2, and pigz for parallel compression. - **Backup verification** — built-in data verification to confirm backup integrity. **The catch:** Barman requires a dedicated backup server. This is a real infrastructure cost and operational overhead, especially for small teams. It also doesn't support block-level incremental backups at the same granularity as pgBackRest — Barman works at the file level with rsync. And like pgBackRest, it's PostgreSQL-only. Barman is licensed under GNU GPL 3, and EDB's commercial support makes it a strong choice for enterprises that need SLAs on their backup tooling. ## WAL-G: Cloud-Native Backup for Multi-Database Environments WAL-G, currently on its v3.0.x release series, takes a fundamentally different architectural approach. Originally created at Yandex and now community-maintained under the Apache 2.0 license, it's written in Go and designed from the ground up for cloud object storage. **Where WAL-G stands out:** - **No backup server required** — WAL-G pushes backups directly from the database host to cloud storage (S3, GCS, Azure Blob). No intermediate staging on local filesystem, no dedicated backup server. For cloud-native teams, this eliminates an entire infrastructure component. - **16 concurrent upload streams by default** — the `WALG_UPLOAD_CONCURRENCY` setting defaults to 16, maximizing throughput to object storage. This makes WAL-G exceptionally fast for cloud-based backups. - **Multi-database support** — WAL-G supports PostgreSQL, MySQL, MongoDB, MS SQL Server, Redis, Greenplum, and FoundationDB. If you're running a polyglot database environment, one tool covers everything. This is unique among the three. - **pgBackRest backup compatibility (beta)** — WAL-G can read pgBackRest-format backups for `wal-fetch` and `backup-fetch` operations. This is a critical migration path detail: if you're evaluating a move from pgBackRest to WAL-G, you don't necessarily need to re-take all your backups. - **Failover archive storages (experimental)** — store WAL archives in multiple storage backends for redundancy. **The catch:** WAL-G's community maintenance model means there's no single company backing it. With 4,200 GitHub stars, 559 forks, and 73 open pull requests, the community is active — but there's no commercial support option. Delta backups exist but don't reach pgBackRest's block-level granularity. Documentation is more scattered than pgBackRest's or Barman's. WAL-G is roughly 4,200 stars on GitHub — comparable to pgBackRest — but the contributor base is broader, which cuts both ways: more diverse input, but potentially less coordinated development. ## Comparison Table: pgBackRest vs Barman vs WAL-G | Dimension | pgBackRest | Barman | WAL-G | | --- | --- | --- | --- | | **Current Version** | v2.58.0 (Jan 2026) | v3.19.1 (May 2026) | v3.0.x | | **Maintained By** | David Steele + 6-sponsor coalition | EnterpriseDB (EDB) | Community (originally Yandex) | | **Language** | C | Python | Go | | **License** | MIT | GPL v3 | Apache 2.0 | | **Backup Granularity** | Block-level incremental | File-level (rsync) | Delta (file-level) | | **Cloud Storage** | S3, GCS, Azure | S3 (via hooks/scripts) | S3, GCS, Azure (native) | | **Compression** | lz4, zstd, gz, bz2 | gzip, bzip2, pigz | lz4, lzma, zstd, brotli | | **Parallel Backup** | Yes (native) | Yes (pigz) | Yes (16 streams default) | | **Multi-Server Mgmt** | Per-server config | Centralized (one server) | Per-server agent | | **RPO=0 Capable** | No (near-zero via WAL) | Yes (sync streaming) | No (near-zero via WAL) | | **Dedicated Server** | Optional | Required | Not required | | **Multi-DB Support** | PostgreSQL only | PostgreSQL only | 7 databases | | **Commercial Support** | Via sponsors | EDB enterprise support | None | | **Best For** | General-purpose production | Enterprise fleet management | Cloud-native / multi-DB | Based on the benchmark data I maintain at [kunalganglani.com/llm-benchmarks](/llm-benchmarks), I've learned that comparison tables like this one are the most-cited content format for AI search engines — they extract structured data more reliably than prose. The same principle applies here: if you're making a production backup decision, this table is your starting point. ## pgBackRest vs Barman: Head-to-Head The pgBackRest vs Barman decision comes down to three factors: backup granularity, operational model, and commercial support. **Backup granularity:** pgBackRest's block-level incremental backups are its killer feature. On a 5TB database where 2% of data changes daily, pgBackRest's incremental backup captures only the changed blocks. Barman's file-level approach with rsync captures entire changed files — which on PostgreSQL's default 8KB page size means significantly larger incremental backups when changes are spread across many files. **Operational model:** Barman requires a dedicated backup server that pulls data from your PostgreSQL instances. pgBackRest supports both local and remote modes — you can run it on the database server itself or from a remote host. For small teams without the budget or desire to manage a separate backup server, pgBackRest is simpler to operate. **Commercial support:** Barman wins here cleanly. EDB provides enterprise support contracts, which matters for organizations that need SLA-backed tooling. pgBackRest's new consortium model is promising but untested at enterprise support scale. If you're running fewer than 10 PostgreSQL instances and want the best backup performance with minimal infrastructure, pgBackRest is the better choice. If you're managing a fleet of 50+ instances and need centralized management with RPO=0 guarantees and commercial support, Barman is worth the infrastructure overhead. ## pgBackRest vs WAL-G: Head-to-Head The pgBackRest vs WAL-G comparison is really about architecture philosophy: traditional versatility versus cloud-native simplicity. **Cloud-native design:** WAL-G was built for cloud object storage from day one. It streams directly to S3/GCS/Azure with configurable concurrency (default 16 streams), no local staging needed. pgBackRest added cloud storage support incrementally — it works well, but WAL-G's architecture is more naturally aligned with cloud-native deployments running on [Kubernetes](/glossary/kubernetes) or ephemeral infrastructure. **Multi-database environments:** If your stack includes PostgreSQL alongside MySQL, MongoDB, or Redis, WAL-G is the only tool that covers all of them with a single backup solution. This isn't a minor convenience — it means one set of backup scripts, one monitoring integration, one team competency instead of three or four. **Migration path:** WAL-G's beta support for reading pgBackRest-format backups is a significant detail that most comparison articles miss. If you're considering a migration from pgBackRest to WAL-G, you can potentially read your existing pgBackRest backups during the transition period, reducing the risk window. **Raw backup performance:** pgBackRest's block-level incrementals still give it an edge on backup size and speed for large, slowly-changing datasets. WAL-G's concurrent uploads are fast, but delta backups at the file level mean larger incremental sizes. For teams already running everything in AWS/GCP/Azure with [CI/CD](/glossary/ci-cd) pipelines deploying to Kubernetes, WAL-G's no-backup-server model is compelling. For on-premises or hybrid deployments where you need maximum restore flexibility and the smallest possible backup sizes, pgBackRest still wins. ## pgBackRest vs pg_dump: Why Logical Backups Aren't Enough at Scale The question "pgBackRest vs pg_dump" comes up surprisingly often, and the answer is straightforward: pg_dump is not a backup strategy for production databases at scale. It's a logical export tool. Here's why this matters: - **No point-in-time recovery (PITR):** pg_dump creates a snapshot of your data at the moment the dump starts. If your database corrupts at 2:47 PM and your last pg_dump ran at midnight, you've lost nearly 15 hours of data. pgBackRest, Barman, and WAL-G all support PITR through WAL archiving — you can recover to any point in time. - **Performance at scale:** pg_dump on a 2TB database can take hours and puts significant load on the primary server. Physical backup tools like pgBackRest use PostgreSQL's built-in backup API and parallel processing to complete in a fraction of the time. - **Restore time:** pg_dump restores require rebuilding indexes, constraints, and sequences. A 2TB pg_dump restore can take 4-8 hours. Physical restore from pgBackRest typically takes 30-60 minutes for the same dataset because it's restoring data files directly. - **Consistency during backup:** pg_dump takes a serializable snapshot, which works but can conflict with long-running transactions. Physical backups use PostgreSQL's checkpoint mechanism, which is designed for exactly this purpose. That said, pg_dump has a role in a comprehensive backup strategy. It's useful for logical migrations between PostgreSQL major versions, selective table-level exports, and creating portable database copies for development environments. The right approach is pg_dump _alongside_ a physical backup tool — not instead of one. Running this blog's [agent pipeline](/blog/evaluate-ai-agents-production-testing) taught me that backup and disaster recovery are the boring infrastructure decisions that matter most. The data layer is the one thing you absolutely cannot afford to lose. When I was designing the pipeline's data persistence layer, the first decision was ensuring idempotent state recovery — the same principle that makes physical backup tools essential for production PostgreSQL. ## Which PostgreSQL Backup Tool Should You Choose? Here's a decision framework based on the dimensions that actually matter for production teams: **Choose pgBackRest if:** - You're running 1-20 PostgreSQL instances - Your databases are large (500GB+) and you need minimal incremental backup sizes - You want the most feature-rich tool with the best backup granularity - You're comfortable with the consortium-backed maintenance model - You need both local and cloud storage repositories - You're PostgreSQL-only **Choose Barman if:** - You're managing a fleet of 20+ PostgreSQL instances from a central location - Your organization requires RPO=0 (zero data loss guarantee) - You need commercial enterprise support with SLAs from EDB - You have the infrastructure budget for a dedicated backup server - Compliance requirements demand a commercially-backed tool **Choose WAL-G if:** - Your infrastructure is cloud-native (Kubernetes, ephemeral compute, object storage) - You run multiple database engines (PostgreSQL + MySQL + MongoDB) - You want the simplest possible setup — no backup server, no complex configuration - You're comfortable with community-maintained tooling without commercial support - You're considering migrating away from pgBackRest (WAL-G can read pgBackRest backups in beta) For most teams reading this, pgBackRest is still the right answer. Its block-level incremental backups, parallel restore, multi-repository support, and now diversified sponsorship make it the strongest general-purpose option. The April 2026 crisis didn't weaken pgBackRest — it actually stress-tested the PostgreSQL ecosystem's ability to rally around critical infrastructure, and the ecosystem passed. ## How to Migrate from pgBackRest to WAL-G or Barman If the maintenance scare did push you toward evaluating alternatives, here's what the migration path looks like. **pgBackRest to WAL-G:** WAL-G's beta pgBackRest compatibility layer can read your existing pgBackRest backups using `wal-fetch` and `backup-fetch` commands. This means you can install WAL-G alongside pgBackRest, configure it to read your existing backup repository, and run both tools in parallel during a transition period. Once you've validated WAL-G's backup and restore cycle independently, you can decommission pgBackRest. The key risk is that the compatibility is still in beta — test restore operations thoroughly before cutting over. **pgBackRest to Barman:** There's no direct compatibility layer here. You'll need to stand up a Barman server, configure it to manage your PostgreSQL instances, and run parallel backups for a transition period (typically 2-4 weeks) until you have a full Barman backup history that meets your retention policy. Barman's `barman-cli` package installs on the PostgreSQL server side for WAL shipping, and configuration is more involved than WAL-G but well-documented in [EDB's official docs](https://www.enterprisedb.com/docs/supported-open-source/barman/). In both cases, the migration pattern is the same: run the new tool alongside the old one, validate restore operations in a non-production environment, maintain parallel backups for your full retention window, then cut over. Never migrate backup tools without a parallel-run period. The one thing worse than a backup tool maintenance scare is discovering your new backup tool doesn't actually work during a real incident. This is one of those things where the boring answer is actually the right one. Plan the migration, test the restore, run parallel, cut over. No shortcuts. ## The Sponsorship Model as a Risk Signal The pgBackRest crisis revealed something important about how we evaluate open-source infrastructure tools: the sponsorship model is a proxy for project health, and most teams never look at it. Consider the three tools through this lens: - **Barman** is backed by EnterpriseDB, a commercial entity with revenue tied to PostgreSQL success. EDB's incentive to maintain Barman is directly aligned with its business model. Risk: if EDB were acquired or pivoted away from PostgreSQL (unlikely but not impossible), Barman would face the same single-sponsor problem pgBackRest had. - **pgBackRest** is now consortium-backed by 6 sponsors. This is actually the most resilient model of the three — no single sponsor's departure would kill the project. Risk: coordinating 6 sponsors' priorities could slow development, and the model is untested over time. - **WAL-G** is community-maintained with no formal sponsorship structure. It originated at Yandex but has since moved to community ownership. Risk: no guaranteed funding stream means maintainer burnout is the primary threat. With 73 open pull requests, there are signs of community engagement — but also signs that review bandwidth is stretched. For enterprise risk management, Barman's commercial backing is the safest bet. For long-term sustainability, pgBackRest's consortium model may prove more durable. WAL-G's community model works until it doesn't — and there's no rescue playbook written yet. This ties into a broader pattern I've seen across the [open-source sustainability crisis](/blog/open-source-sustainability-crisis) hitting the tech industry. When I built this site's multi-agent publishing pipeline, one of the early lessons was that choosing dependencies with clear maintenance commitments matters more than choosing dependencies with the most features. Deterministic gates before LLM review catch more than doubling the review model's size — and deterministic maintenance funding catches more than hoping the community will step up. ## What RPO and RTO Mean for Your PostgreSQL Backup Strategy For teams newer to disaster recovery planning, these two metrics determine which tool you need: **RPO (Recovery Point Objective)** is how much data you can afford to lose. An RPO of 1 hour means you're OK losing up to 1 hour of transactions. An RPO of 0 means you cannot lose a single committed transaction. All three tools achieve near-zero RPO through continuous WAL archiving, but only Barman achieves true RPO=0 through synchronous streaming replication. **RTO (Recovery Time Objective)** is how fast you need to be back online. An RTO of 15 minutes is aggressive. An RTO of 4 hours is common for non-critical systems. pgBackRest's parallel restore is typically the fastest option here — restoring a 2TB database in under an hour is achievable with sufficient I/O bandwidth. If your RPO requirement is under 5 minutes and your RTO is under 30 minutes for a multi-terabyte database, pgBackRest is the strongest option. If your RPO must be exactly 0, Barman is the only tool that guarantees it. If your RTO is relaxed (hours, not minutes) and your infrastructure is cloud-native, WAL-G's simplicity makes it the pragmatic choice. The PostgreSQL ecosystem has [excellent tooling at the database layer](/blog/postgresql-vs-mysql-2026) — and these three backup tools are proof of that. But choosing the right one requires understanding your actual RPO and RTO requirements, not just picking the most popular option. ## FAQ ### Is pgBackRest still maintained in 2026? Yes. After a 21-day maintenance crisis in April-May 2026, pgBackRest was rescued by a coalition of six sponsors: AWS, Supabase, Percona, pgEdge, Tiger Data, and Eon.io. The project is now on a diversified funding model, which is arguably more sustainable than its previous single-sponsor arrangement with Crunchy Data. ### What is the best PostgreSQL backup tool for production? pgBackRest is the best general-purpose choice for most production PostgreSQL deployments due to its block-level incremental backups, parallel restore, and multi-repository support. Barman is better for large fleet management with RPO=0 requirements. WAL-G is best for cloud-native environments running multiple database engines. ### What is the difference between pgBackRest and pg_dump? pgBackRest performs physical backups of PostgreSQL data files and WAL segments, enabling point-in-time recovery and parallel restore. pg_dump performs logical exports of database objects as SQL statements. pg_dump cannot do PITR, is much slower at scale, and should not be used as a primary backup strategy for production databases. Use pg_dump alongside a physical backup tool, not instead of one. ### Which PostgreSQL backup tool is easiest to set up? WAL-G is the easiest to set up because it requires no dedicated backup server and pushes directly to cloud object storage with minimal configuration. pgBackRest is moderate — more configuration options but well-documented. Barman is the most complex, requiring a dedicated backup server and centralized management setup. ### Can WAL-G read pgBackRest format backups? Yes, WAL-G has beta support for reading pgBackRest-format backups using its `wal-fetch` and `backup-fetch` commands. This provides a migration path for teams moving from pgBackRest to WAL-G, allowing them to access existing backups during the transition period. The feature is still experimental, so thorough testing is required before relying on it. ### Does Barman require a dedicated backup server? Yes. Barman is designed around a centralized architecture where a dedicated backup server manages backups for multiple PostgreSQL instances. This adds infrastructure cost but enables centralized management, which is a significant advantage for teams managing large database fleets. pgBackRest supports both local and remote modes, while WAL-G requires no backup server at all. The PostgreSQL backup landscape just went through its most dramatic three weeks in years. Whether you're running [production AI](/pillars/ai-engineering-production) workloads on Postgres, managing a fleet of application databases, or running a single critical instance — the right backup tool is the one you've actually tested a restore from. Not the one with the most GitHub stars, not the one your last company used, not the one a blog post told you to pick. Run a restore drill this month. If it works, you've got a backup strategy. If it doesn't, you've got a resume update to write. Photo by Lightsaber Collection on Unsplash. ## FAQ ### Is pgBackRest still maintained in 2026? Yes. After a 21-day maintenance crisis in April-May 2026, pgBackRest was rescued by a coalition of six sponsors: AWS, Supabase, Percona, pgEdge, Tiger Data, and Eon.io. The project is now on a diversified funding model, which is arguably more sustainable than its previous single-sponsor arrangement with Crunchy Data. ### What is the best PostgreSQL backup tool for production? pgBackRest is the best general-purpose choice for most production PostgreSQL deployments due to its block-level incremental backups, parallel restore, and multi-repository support. Barman is better for large fleet management with RPO=0 requirements. WAL-G is best for cloud-native environments running multiple database engines. ### What is the difference between pgBackRest and pg_dump? pgBackRest performs physical backups of PostgreSQL data files and WAL segments, enabling point-in-time recovery and parallel restore. pg_dump performs logical exports of database objects as SQL statements. pg_dump cannot do PITR, is much slower at scale, and should not be used as a primary backup strategy for production databases. ### Which PostgreSQL backup tool is easiest to set up? WAL-G is the easiest to set up because it requires no dedicated backup server and pushes directly to cloud object storage with minimal configuration. pgBackRest is moderate — more configuration options but well-documented. Barman is the most complex, requiring a dedicated backup server and centralized management setup. ### Can WAL-G read pgBackRest format backups? Yes, WAL-G has beta support for reading pgBackRest-format backups using its wal-fetch and backup-fetch commands. This provides a migration path for teams moving from pgBackRest to WAL-G, allowing them to access existing backups during the transition period. The feature is still experimental, so thorough testing is required. ### Does Barman require a dedicated backup server? Yes. Barman is designed around a centralized architecture where a dedicated backup server manages backups for multiple PostgreSQL instances. This adds infrastructure cost but enables centralized management, which is a significant advantage for teams managing large database fleets.