Move to a newer minor or major version of EDB Postgres Distributed (PGD) without necessarily changing your Postgres version. Upgrading PGD on individual nodes happens either in place or by replacing a node outright. You don't need to back up and restore when upgrading PGD.
See Planning your upgrade for guidance on rolling versus full-downtime upgrades, choosing how to upgrade each node, rolling upgrade considerations, and reviewing compatibility changes and release notes before you upgrade.
Note
This section covers manually installed or CLI-driven clusters. If your cluster is deployed with Trusted Postgres Architect (TPA), EDB Postgres Distributed for Kubernetes, or Hybrid Manager, see Upgrading with other deployment methods instead.
Performing a minor PGD upgrade
A minor version upgrade (for example, 6.3 to 6.4) doesn't need the routing-tool migration a major version upgrade does, since minor versions within the same major release stay compatible at the consensus protocol level. All it takes is installing the new PGD packages and restarting Postgres, one node at a time or all at once. See Performing a minor PGD upgrade for the complete procedure.
Performing a major PGD upgrade
Moving to a new major PGD version also means moving off the connection-routing tool tied to your current version: HARP Proxy for a PGD 4 cluster, or PGD Proxy for a PGD 5 cluster, in favor of the built-in Connection Manager. Because of this move, the complete procedure, including the full-downtime and rolling options described in Planning your upgrade, is documented on a dedicated page for each source version:
- Upgrading PGD 4 to PGD 6 — for a PGD 4.4.1 cluster using HARP Proxy.
- Upgrading PGD 5 to PGD 6 — for a PGD 5.9 cluster using PGD Proxy.
If you're also upgrading Postgres to a new major version at the same time, see Upgrading Postgres and PGD together instead, which has a dedicated combined procedure for each source version.