Description

This rule checks that the database engine version running on a Managed Database cluster is still within the vendor's supported version lifecycle, which is distinct from patch-level currency. DigitalOcean publishes the set of supported major versions per engine along with end-of-life dates, and new clusters default to a current major version (for example, new Advanced Edition PostgreSQL clusters default to v18).

The rule compares the cluster's reported engine version against DigitalOcean's supported-version list and flags any cluster running a major version that has reached or is nearing end-of-life, so an upgrade can be planned before support ends.

  • Clusters running a major engine version that has passed DigitalOcean's published end-of-life date

  • Clusters on a version approaching end-of-life with no upgrade scheduled

Rationale

Once an engine major version reaches end-of-life the vendor stops issuing security fixes for it entirely, so no patching cadence can keep it safe — the version itself is unmaintained. Running an unsupported version leaves known vulnerabilities permanently unaddressed.

Major-version upgrades on DigitalOcean are irreversible and invalidate older backups for point-in-time recovery, so they must be planned and tested ahead of the end-of-life deadline rather than rushed after support lapses.

Impact

Pros:

  • Continues to receive security patches and vendor support

  • Access to performance and feature improvements in newer versions

  • Avoids an emergency, unplanned upgrade after end-of-life

Cons:

  • Major upgrades are irreversible and past backups can no longer be used for point-in-time recovery afterward

  • Application compatibility must be validated against the new version first

  • The upgrade runs during a maintenance window and may briefly affect the workload

Default Value

New clusters are created on a current engine version (for example, new Advanced Edition PostgreSQL clusters default to v18); DigitalOcean publishes the supported versions and end-of-life dates for each engine.

Pre-Requisite

  • DigitalOcean Control Panel access with a role that can upgrade the cluster

  • A staging or forked copy of the cluster to test application compatibility on the target version

  • Awareness of DigitalOcean's published end-of-life date for the current engine version

  • Optional: a DigitalOcean API token or doctl authenticated (doctl auth init) to read the version

Remediation

Test Plan

Using the DigitalOcean Control Panel:

  1. In the Control Panel, open Databases and click the cluster name.

  2. On the Overview page, find the CURRENT VERSION section and note the engine major version.

  3. Compare that version against DigitalOcean's published supported-versions / end-of-life list for the engine.

  4. Pass: The cluster's engine version is within the currently supported lifecycle.

  5. Fail: The cluster runs a version at or past its end-of-life date.

Using doctl or the API:

Read the cluster's engine and version, and list the versions DigitalOcean currently supports.

doctl databases get <database-cluster-id> --format ID,Engine,Version
doctl databases options
curl -s -X GET "https://api.digitalocean.com/v2/databases/<database-cluster-uuid>" -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" | jq '{engine:.database.engine, version:.database.version}'

Pass if the reported engine version appears in DigitalOcean's current supported-versions list. Fail if the version is end-of-life or no longer offered.

Implementation Steps

Using the DigitalOcean Control Panel:

  1. First fork the cluster (or restore into a new cluster) and test the application against the target version.

  2. On the production cluster's Overview page, scroll to the CURRENT VERSION section and click 'Upgrade Now'.

  3. Let the control panel run its upgrade compatibility check, then confirm to proceed.

  4. Validate the application after the upgrade completes.

Using doctl or the API:

Major-version upgrades are performed from the Control Panel (Upgrade Now); DigitalOcean does not document a doctl or API command for major-version upgrades, so there are no API commands for this step.

Backout Plan:

  1. A completed major-version upgrade is irreversible and cannot be rolled back in place.

  2. If the upgrade must be undone, provision a new cluster from a pre-upgrade backup (create-from-backup / fork to a point in time before the upgrade) and repoint applications at it.

  3. This is why testing on a fork before upgrading production is required.

References:

  1. How to Upgrade PostgreSQL to a New Version

  2. PostgreSQL Limits (supported versions and end-of-life)

  3. doctl databases get