Upgrading from 2026.8 to 2026.9 (Innovation Release) Innovation Release

Suggest edits

Upgrade from 2026.8 to 2026.9.

Role: Infrastructure engineer

Prerequisites

  • Administrative access to the Kubernetes cluster (kubectl, helm).
  • Required tools:

Upgrade 2026.8 → 2026.9

HM and the operator follow independent version schemes, and the 2026.8 → 2026.9 upgrade needs operator change: the 2026.9 release requires operator version 2.2 or later. The new pgd scenario depends on it too — earlier operator versions don't recognize pgd and silently drop it from your manifest rather than reporting an error.

Complete the steps in the order given:

  1. Upgrade the operator to 2.2 or later.
  2. Review and update your installation scenarios.
  3. Update spec.version and trigger the upgrade.
Important

The order matters. Operator versions earlier than 2.2 don't recognize pgd and silently drop it — you get no error, so a manifest that looks applied may not list it. Add scenarios only after the operator is on 2.2 or later, and before you bump spec.version, then read the resource back with kubectl get hybridcontrolplane <name> -o jsonpath='{.spec.scenarios}' to confirm it persisted.

Create new secrets

Before upgrading, create the new secrets required for this release:

edbctl hm create-install-secrets --version v2026.9.0

For more CLI options, see edbctl hybrid-manager. To customize your component's secrets, see Customizing secrets.

Upgrade the operator

Red Hat OpenShift

On RHOS, upgrade the operator through OperatorHub (OLM) by switching the subscription channel to stable. See Upgrade the operator on Red Hat OpenShift. Do not use edbctl hm upgrade-operator on RHOS.

The commands below use edb-hcp-operator-system — use the namespace where your operator is actually installed. If you migrated from the bootstrap method, the conversion transfers Helm ownership onto edbpgai-bootstrap, so use that namespace instead.

Upgrade the edb-hcp-operator Helm chart using edbctl:

edbctl hm upgrade-operator \
  --release-name edb-hcp-operator \
  --namespace edb-hcp-operator-system \
  --registry-uri docker.enterprisedb.com/pgai-platform \
  --registry-username pgai-platform \
  --registry-password <password>

Or upgrade directly with Helm:

Note

<OPERATOR_VERSION> refers to the operator chart version, which follows its own 2.x versioning scheme and is separate from the HM version (2026.9). The pgd scenario requires operator version 2.2 or later.

  1. Create the values file:

    cat <<EOF > edb-hcp-operator.values.yaml
controllerManager:
  manager:
    image:
      repository: docker.enterprisedb.com/pgai-platform/edb-hcp-operator/manager
      tag: <OPERATOR_VERSION>
imagePullSecrets:
  - name: edb-cred
EOF

  2. Run the upgrade:

    helm upgrade --install \
  --version <OPERATOR_VERSION> \
  --values edb-hcp-operator.values.yaml \
  -n edb-hcp-operator-system \
  edb-hcp-operator enterprisedb-edbpgai/edb-hcp-operator

Review and update your installation scenarios

Two installation scenario changes in 2026.9. Check your HybridControlPlane manifest against both before you continue.

List every scenario explicitly

Operator 2.2 — which 2026.9 requires — no longer fills in a default set. Earlier operator versions installed core, dbaas, ai, analytics, migration, and marketplace when spec.scenarios was omitted; operator 2.2 or later installs only core.

Important

If your manifest relies on the old default, list the scenarios you want before you upgrade the operator. Applying a manifest that omits spec.scenarios against operator 2.2 or later removes the components of every scenario except core, along with the data they hold.

Update spec.scenarios to include pgd

From Innovation Release 2026.9 onwards, pgd — which provisions and manages Distributed High Availability (DHA) clusters — is controlled by its own installation scenario, separated from dbaas.

If you use DHA clusters, you must explicitly add pgd to your spec.scenarios list before upgrading to Innovation Release 2026.9.

Important

Add pgd to every location that hosts, or will host, DHA clusters — including secondary locations. If you don't add pgd to a location's scenario list, its existing DHA clusters will be deleted (and new ones will not be allowed to be created).

Upgrade Hybrid Manager

  1. Update spec.version to v2026.9.0 in your HybridControlPlane manifest and apply it:

    kubectl apply -f hybridmanager.yaml

  2. Trigger the upgrade:

    kubectl annotate hybridcontrolplane edbpgai --overwrite edbpgai.com/ready-for-upgrade=true

  3. Monitor progress:

    kubectl get hybridcontrolplane edbpgai -w

Upgrading multi-DC deployments

In a multi-DC deployment, all locations must run the same HM version. Upgrade the primary location first, then upgrade each data-only secondary location to the same version immediately after. For the full procedure, see Upgrading a multi-DC deployment.

Troubleshooting upgrade job failures

The upgrade operator creates and manages upgrade jobs automatically. If an upgrade job fails and doesn't reach a Complete or Succeeded state, the operator pauses and retries. It doesn't proceed to apply updated manifests until the job succeeds.

Note

The operator owns and manages the upgrade job exclusively. Don't create upgrade jobs manually, as doing so can conflict with the operator's reconciliation loop.

To investigate a failed upgrade job:

  1. Check the status of upgrade jobs:

    kubectl get jobs -n edbpgai-bootstrap -l edbpgai.edb.com/hm-upgrader=true

  2. Check the logs for the failed job:

    kubectl logs job/<job-name> -n edbpgai-bootstrap

    Replace <job-name> with the name of the failed job from the previous command.

  3. Check the HybridControlPlane status for upgrade-related events:

    kubectl describe hybridcontrolplane edbpgai

If the issue persists after the operator retries, contact EDB support with the job logs.

← Prev

Upgrade the operator on Red Hat OpenShift

↑ Up

Upgrading Hybrid Manager

Next →

Upgrading from 2026.7 to 2026.8 (Innovation Release)