Disaster Recovery Comes to WarehousePG on EDB Postgres® AI

A warm standby cluster for your analytical data, built by the industry leaders in Postgres disaster recovery

A government agency’s data center goes dark, whether from a storm, a grid failure, or a flooded facility. The analytical warehouse behind benefits payments, tax processing, and case management goes down with it. Now you’e stuck: There’s no failing over to spare capacity in some other region, not when residency rules dictate exactly where that data is allowed to run.

That’s exactly why we’re announcing Disaster Recovery (DR) for WarehousePG on EDB Postgres AI (EDB PG AI). You can now keep a standby current with production down to the minute, not last night’s backup. You decide when to fail over or promote, not a vendor. And you can manage the whole thing from WarehousePG Enterprise Manager (WEM), right alongside everything else you already run there.

What disaster recovery actually requires

Everyone agrees disaster recovery matters. Many enterprises implement nightly backups and a plan to restore “as needed,” but for a warehouse holding petabytes of your most important data, that plan falls apart on contact with a real outage. A full restore can take hours—sometimes more than a day—and by the time it finishes, you’ve already blown the recovery window your regulators (and customers) expect you to hit.

Warm disaster recovery (DR) is a different standard. Instead of a copy sitting cold in object storage, you keep a second cluster running and continuously in sync with production. There are no backup windows to schedule, no scheduled load jobs racing the clock, and nothing locking your tables while analysts and agents are trying to work. When you need it, recovery is measured in minutes, not hours or days. One banking customer went from a two-day recovery window to 16 minutes, a roughly 180x improvement. You can read that story in this technical blog.

The reason it works so well

Underneath, WarehousePG really is Postgres, so DR behaves the way seasoned Postgres teams already expect. That’s also why we put WarehousePG and Postgres disaster recovery experts side by side to work through the hard parts of DR at warehouse scale, rather than treating it as a separate problem. And because we’re among the world’s top Postgres contributors, we’re ensuring that WarehousePG keeps pace with where Postgres goes next.

That continuity is also why WarehousePG exists in the first place. When Broadcom took Greenplum closed source, EDB forked it to give the community an open, Postgres-based path forward. Disaster recovery is a natural extension of that work, reinforcing what EDB Postgres AI for WarehousePG already does well:

• Sovereignty: You choose where the standby lives and where you fail over, so your data stays inside the region or jurisdiction it’s required to—even on your worst day.

• No surprises: No running every load twice into a duplicate cluster, and no paying for hardware that sits idle. Your standby can be a smaller footprint or live in the cloud.
• One control plane: High availability and DR are engineered into the MPP engine and managed in WEM alongside everything else. No third-party add-ons, no extra vendor surface area.
• A supported foundation: WarehousePG’s built-in high availability runs on proven replication and a supported kernel, so the failover path is one you can actually rely on.

Figure 1. WarehousePG Enterprise Manager provides an overview of primary and DR cluster status, including backup counts and a timeline of existing restore points. There is also GUI-based tooling for configuring clusters, assigning intermediate storage layers, managing existing backups, and tracking WAL growth.

Built on EDB’s Postgres DR expertise and Barman

Protecting Postgres from disasters is core to what EDB does. We’re among the world’s foremost Postgres contributors, and we’ve built and supported mission-critical Postgres DR for years. Disaster Recovery for WarehousePG is that expertise pointed at the warehouse. It runs on Barman, the open source backup and recovery engine that’s protected Postgres databases since 2011. It’s one of the most widely deployed backup and recovery tools in the Postgres ecosystem, with new releases still shipping regularly. Rather than inventing a DR stack from scratch, we brought years of hardened tooling to WarehousePG from day one. That’s real time saved and real risk avoided.

Disaster Recovery for WarehousePG runs on the same proven replication that already keeps WarehousePG’s segment mirrors and standby coordinator in sync, layered on the Postgres write-ahead log (WAL) that records every change as it happens. That’s now extended across a full standby cluster.

Other ways to use your standby cluster

Warm DR is useful for more than recovery from disasters. You’re covered for the day you hope never comes, but the standby doesn’t just wait around for it. There’s more value to unlock the other 364 days a year.

• Lower-risk cloud migration: Stand up a cloud-based standby and use it as a controlled path to move analytical workloads off-premises, without a big-bang cutover.

• Scenario and load testing: Promote a standby to replay a peak event (say, a high-traffic filing deadline at double the volume) and run models against it without touching production.
• Heavy reporting, offloaded: Spin up a point-in-time restore for end-of-month or end-of-quarter reporting so those big queries run somewhere else, then release the compute when you’re done.

Same investment, three more reasons it pays for itself.

Get started

Disaster recovery is the difference between a bad day and a catastrophe. Now it’s built into the premier Postgres-based data warehouse, backed by the team that has protected Postgres for years.

Two easy next steps: Explore EDB PG AI for WarehousePG to see the full platform, and dive into the docs when you’re ready to see how DR fits your environment.