Assessing an existing application for PGD

Before migrating an existing application to PGD, assess its compatibility to identify schema patterns, backup gaps, and replication configurations that need to change. The pgd assess command is designed for Postgres deployments not yet running PGD, including single-instance setups and physical replication clusters.

Using pgd assess

If you have a running Postgres instance serving your application, use pgd assess to evaluate its compatibility with PGD. The command connects to your Postgres instance, checks the schema and internal state of the database for the most common application patterns, and provides recommendations on how to adapt them for PGD. It doesn’t analyze live traffic or actual queries of your application.

pgd assess --dsn <connection_string>

For full details on the command and its output, see Using pgd assess .

Reviewing backup strategies

Identify what tools are currently used for backup. A PGD cluster spans multiple nodes and locations, increasing disk space and backup bandwidth requirements. Plan for at least one backup per group or location rather than backing up every node individually.

An alternative strategy is to back up a single node and rebuild the rest of the cluster from it. Restore to a single-node PGD cluster first, then run pgd node setup for each additional node to join them via a physical join. See Backup and recovery for details.

Reviewing replication and CDC setups

By default, outgoing logical replication to a data warehouse or event streaming pipeline is tied to a single PGD node. Logical replication slots aren’t replicated across the cluster unless CDC Failover support is explicitly enabled. With CDC Failover support enabled, slots are replicated across nodes, but failover isn’t fully transparent. The consumer must support reconnecting to a new node. See CDC Failover support for details.

Any synchronization with other databases through a two-phase commit (2PC) protocol or XA transactions isn’t compatible with PGD.