Upgrading from 2026.7 to 2026.8 (Innovation Release) Innovation Release

Upgrade from 2026.7 to 2026.8.

Role: Infrastructure engineer

Prerequisites

• Administrative access to the Kubernetes cluster (kubectl, helm).
• Required tools:
  • helm (latest version recommended)
  • kubectl
  • edbctl 1.8.1 or later — see the edbctl compatibility matrix.

Upgrade 2026.7 → 2026.8

HM and the operator follow independent version schemes, and the 1.4.x → 2026.7 upgrade needed no operator change. 2026.8 does: the release requires operator version 2.1 or later. The new marketplace scenario depends on it too — earlier operator versions don't recognize marketplace and reject a manifest that lists it.

Complete the steps in the order given:

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

Create new secrets

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

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

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

Upgrade the operator

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:

1. Create the values file:

   → WrapCopy

   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:

   → WrapCopy

   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 your installation scenarios

Two installation scenarios change in 2026.8. Check your HybridControlPlane manifest against both before you continue.

The marketplace scenario

marketplace — the kapp package manager and the OSS Library apps it deploys, such as Superset, Airflow, and pgAdmin — now has its own scenario instead of belonging to core.

• If your spec.scenarios list already includes ai, the upgrade adds marketplace for you. You don't need to change anything.
• If your list includes only core and you use the OSS Library or marketplace apps, add marketplace to spec.scenarios now.

The dbaas scenario

dbaas isn't new, but its contents are. In 2026.7, upm-api-gucs and pg4k-additional-controllers belonged to core. In 2026.8 they move to dbaas.

This matters on upgrade because a 2026.7 installation that pins spec.scenarios to core is running both components today. After the move they fall outside every scenario that installation selects, and the upgrade removes them.

• If you list scenarios explicitly, add dbaas before you upgrade.
• If you omit spec.scenarios entirely, HM installs the default set — core, dbaas, ai, analytics, migration, and marketplace — so dbaas is already covered and the upgrade removes nothing.

Upgrade Hybrid Manager

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

   → WrapCopy

   kubectl apply -f hybridmanager.yaml

2. Trigger the upgrade:

   → WrapCopy

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

3. Monitor progress:

   → WrapCopy

   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.

To investigate a failed upgrade job:

1. Check the status of upgrade jobs:

   → WrapCopy

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

2. Check the logs for the failed job:

   → WrapCopy

   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:

   → WrapCopy

   kubectl describe hybridcontrolplane edbpgai

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