Upgrading Hybrid Manager v1.4.0 (LTS)

Hybrid Manager (HM) offers a dual release strategy: Long-Term Support (LTS) Releases and Innovation Releases (IR). Because these streams follow different versioning logic, the supported paths for moving among them depend on your current version and the target environment.

Tip

If you want to upgrade your Postgres database clusters instead, see Upgrading database clusters in Hybrid Manager.

Release types

Innovation Releases (IR) are delivered monthly. They focus on continuous platform hardening, workflow improvements, stability, reliability, and introduce smaller, iterative new features. They are ideal for customers and teams that want early access to the latest capabilities and want to follow the leading edge of product development.

Long-Term Support (LTS) releases are delivered twice a year. They consolidate the innovations from preceding monthly releases into a stable, well-tested foundation suited to production deployments that require predictability and an extended support window. Each LTS release is supported for 15 months from its release date, with monthly patch releases throughout that period delivering bug fixes and security updates.

LTSInnovation Release (IR)
Version formatSemantic versioning (for example, 1.x.x)Calendar-based (for example, 2026.x)
Release cadenceBi-annualMonthly
PatchesMonthly patch releases with bug and security fixesNo planned patches—replaced by the next monthly release. Critical fixes, such as CVEs, may result in an unplanned patch.
Upgrade pathOne minor version at a time (for example, 1.3.x → 1.4.y); skipping minor versions not supportedSequential month-to-month upgrades required
Best forProduction environments requiring stability and extended supportDevelopment, testing, or teams wanting leading-edge features
Important

For current support timelines and end-of-support dates, see Platform Compatibility.

IR upgrade paths

You must upgrade month-to-month within the IR stream (for example, 2025.11 → 2025.12). IR streams are not open-ended: twice a year, the stream consolidates into a new LTS version. To continue receiving updates after a consolidation point, you must transition to the newly released LTS version (for example, 1.4.0), which then serves as the foundation for the next IR.

IR sequential upgrade

LTS upgrade paths

LTS releases follow standard semantic versioning (major.minor.patch, for example, 1.3.x). These versions focus on stability, receiving monthly patch releases with bug and security fixes for their full support lifespan.

Minor and patch version upgrades

To upgrade to the next minor version (for example, 1.3.latest to 1.4.0), you must be on the latest available patch of your current minor version first.

Within the same minor version, patch upgrades are flexible: you may upgrade from any patch to any higher patch (for example, 1.3.1 to 1.3.5) without installing intermediate patches.

LTS minor and patch releases

Major version upgrades

When a new major version (for example, 2.0) is released, you must be running the latest available minor and patch release of the 1.latest.latest stream to perform the upgrade.

LTS major version upgrade

Cross-stream upgrade paths

Moving between LTS and Innovation Releases is possible but has specific constraints.

Cross-stream upgrade paths

Innovation Release to LTS

You can move from the final Innovation Release of a cycle to the LTS release that consolidates those features, but not from any other IR in the cycle.

To determine if your current IR supports transitioning to LTS, check the upgrade instructions for that specific version—they indicate whether the transition is supported.

LTS to Innovation Release

You can upgrade an LTS release to its immediate succeeding Innovation Release. You can't jump to an arbitrary or later IR—upgrade to the immediate successor first, then follow the sequential IR upgrade path.

Warning

Once you move from an LTS release to an Innovation Release, you can't return to LTS until the next consolidation point (see Innovation Release to LTS above). Consolidation points occur twice a year.

Service availability during upgrades

Some upgrades may trigger an automatic restart of your HM-managed Postgres database clusters. To avoid unexpected interruptions, check the service availability notes in the specific upgrade guide you are following.

Operator 2.0.0 on Red Hat OpenShift

Upgrade the EDB Postgres AI operator to 2.0.0 on Red Hat OpenShift by switching the OperatorHub subscription to the stable channel.

1.3.x to 1.4.0

Follow the step-by-step procedures for upgrading from the latest HM 1.3.x patch to HM 1.4.0.

2026.5.1 to 1.4.0

Follow the step-by-step procedures for upgrading from HM 2026.5.1 to HM 1.4.0.

2026.4 to 2026.5.1

Follow the step-by-step procedures for upgrading from HM 2026.4 to HM 2026.5.1.

2026.3 to 2026.4

Follow the step-by-step procedures for upgrading from HM 2026.3 to HM 2026.4.

2026.2 to 2026.3

Follow the step-by-step procedures for upgrading from HM 2026.2 to HM 2026.3.

2026.1 to 2026.2

Follow the step-by-step procedures for upgrading from HM 2026.1 to HM 2026.2.

2025.12 to 2026.1

Follow the step-by-step procedures for upgrading from HM 2025.12 to HM 2026.1.

2025.11 to 2025.12

Follow the step-by-step procedures for upgrading from HM 2025.11 to HM 2025.12.

1.3.x to 2025.12

Follow the step-by-step procedures for upgrading from HM 1.3.x to HM 2025.12.