PostgreSQL versioning policy

This document describes the lifecycle of major PostgreSQL versions in Yandex Cloud. The policy is based on the PostgreSQL community's official support cycle and seeks to strike a balance between stable cluster operation and maintaining a modern, secure infrastructure.

PostgreSQL version lifecycle terms and stagesPostgreSQL version lifecycle terms and stages

In Managed Service for PostgreSQL, each major PostgreSQL version has the following 5-year lifecycle:

¹ The periods are relative to the major version release date. The exact status change dates are officially announced by the service.

Features for each versionFeatures for each version

Depending on PostgreSQL version status, the following operations are available for clusters:

Key principles of the PostgreSQL versioning policyKey principles of the PostgreSQL versioning policy

The PostgreSQL versioning policy is based on the following key principles:

• Support duration. Each major version remains either New or Supported for four and a half years.
• Incremental deprecation. In its fifth year, the version get the Deprecated status, and it becomes impossible to create new clusters six months before the end of life date.
• Active notification: Six months before EOL, Managed Service for PostgreSQL begins an active campaign to notify customers about the need to update.
• End of life: On reaching EOL (end of fifth year), clusters running obsolete versions get **automatically updated ** to the latest Supported version. If the update is not possible for technical reasons, the cluster will be stopped. Before it stops, the final backup will be automatically uploaded to the customer's Object Storage bucket. After the cluster is stopped and the backup is uploaded, the cluster will be deleted.

Update policyUpdate policy

• Minor updates (within a major version, e.g., 15.1 → 15.2) are installed automatically as part of maintenance performed during the cluster's specified maintenance window or at the customer's request. These updates contain security and bug fixes. The update requires a short, successive reboot of the cluster hosts.
• Major updates (major version changes, e.g., 15.x → 16.x) are user-initiated, except for automatic updates for versions that have reached EOL. We highly recommend you to update before the EOL date.

Automatic update and stopping procedureAutomatic update and stopping procedure

For clusters still running versions with expired support (EOL), Managed Service for PostgreSQL initiates an automatic update.

1. Notification: Owners of clusters based on Deprecated versions will get a series of official email notifications: the first one 6 months before EOL, and then 90 and 30 days before the scheduled start date of the auto-update campaign.
2. Automatic update: Three months before EOL, Managed Service for PostgreSQL begins the process of auto-updating clusters that had not been updated by their owners.
3. Stopping as a final measure: If an automatic update is not possible, Managed Service for PostgreSQL will stop the cluster. Before it stops, the final backup will be created and saved in the customer's bucket.
4. Access to data: Once the cluster is stopped, the responsibility for data is transferred to the customer. You can restore the data only in your own infrastructure, e.g., Yandex Compute Cloud VMs, using the backup you export.

NotificationsNotifications

Managed Service for PostgreSQL provides these upcoming update notifications in advance:

• Entering Deprecated status (prohibits creating new clusters).
• Six months ahead of EOL (start of active notification phase).
• Start of the automatic update campaign: 90 and 30 days before the start of the campaign.

Versioning scheduleVersioning schedule

The current status of major PostgreSQL versions is based on the official support schedule.

² Exact dates of transitions between statuses will be announced additionally. The EOL dates match the PostgreSQL community end of support dates.