Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Amazon RDS PostgreSQL 13 automatically upgraded to PostgreSQL 18.3 months after end of standard support

0

I’m trying to understand the lifecycle behavior for an Amazon RDS for PostgreSQL instance after PostgreSQL 13 reached RDS end of standard support on February 28, 2026.

The instance was still running PostgreSQL 13 in August 2026. During its configured maintenance window on August 15, RDS performed the following upgrades:

13.20.R1 → 13.23-rds.20260224.R1 → 18.3.R2

The RDS event history shows that the first upgrade was a minor-version upgrade and the second was a major-version upgrade. The instance currently has:

EngineLifecycleSupport = open-source-rds-extended-support-disabled AutoMinorVersionUpgrade = true

I also checked Cost Explorer for the period from March 1 through August 15, 2026 and found no RDS Extended Support charges.

I have already checked the available CloudTrail Event History and did not find a customer-initiated ModifyDBInstance event associated with the major upgrade. AWS Health shows the PostgreSQL 13 end-of-standard-support notification, but the notification I can still access does not specify an automatic-upgrade date in August.

My questions are:

  1. For RDS PostgreSQL instances with Extended Support disabled, is there a documented schedule or grace period between RDS end of standard support and the automatic major-version upgrade?
  2. Why might an instance remain on PostgreSQL 13 for several months after February 28 and then be automatically upgraded during an August maintenance window?
  3. How does RDS determine the target major version for this automatic lifecycle upgrade? In this case, the instance was upgraded directly from PostgreSQL 13.23 to PostgreSQL 18.3 rather than PostgreSQL 14, 15, 16, or 17.
  4. Is there any public AWS documentation that describes the maintenance-window selection and target-version-selection logic for this Extended Support-disabled upgrade process?

I’m specifically looking for documentation or clarification of the RDS lifecycle mechanism rather than general instructions for manually performing a PostgreSQL major-version upgrade.

  • Florian Turnwald EXPERT
    a month ago

    If my answer was helpful, I would appreciate it if you could mark it as the accepted answer.

Topics
Database
Tags
PostgreSQL
Language
English

asked 2 months ago132 views

1 Answer
1

1. Upgrade Timing & Phased Rollout

When an engine reaches End of Standard Support and Extended Support is disabled (open-source-rds-extended-support-disabled), AWS does not force upgrades universally on the exact EOL date. Forced lifecycle upgrades are executed in a phased global rollout during configured maintenance windows. This process routinely takes several months, which explains the gap between February and August.

2. Target Version Selection (Directly to 18.3)

To prevent consecutive disruption and avoid upgrading an EOL instance to a version that is also nearing its own EOL (e.g., PG 14 or 15), AWS forces upgrades directly to a newer, long-term default major version. Both PostgreSQL (pg_upgrade) and AWS RDS natively support multi-major version direct upgrades, provided the required minor version baseline (e.g., 13.23) is met first.

3. Absence of CloudTrail Events

CloudTrail records API requests made by IAM principals (customers). Because this forced upgrade was a system-initiated action executed internally by the RDS Control Plane, no ModifyDBInstance API call was generated. System-enforced lifecycle events are pre-announced via the AWS Health Dashboard and logged solely in the RDS Event History.

Official AWS Documentation References:

EXPERT

answered 2 months ago

EXPERT

reviewed 2 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content