PostgreSQL versioning policy in Managed Service for Sharded PostgreSQL

This document describes a Managed Service for Sharded PostgreSQL lifecycle based on PostgreSQL major 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 (shard) operation and maintaining a modern, secure infrastructure.

Terminology and lifecycle stages of PostgreSQL versionsTerminology and lifecycle stages of PostgreSQL versions

In Managed Service for Sharded 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 the PostgreSQL version status, the following operations are available for specific Managed Service for Sharded PostgreSQL shards:

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 shards six months before the end-of-life date.
• Active notification: Six months before EOL, begins an active campaign to notify customers about the need to update.
• End of life: On reaching EOL (end of fifth year), shards running obsolete versions get **automatically updated ** to the latest Supported version. If the update is not possible for technical reasons, the shard will be stopped. Before it stops, the final backup will be automatically uploaded to the customer's Object Storage bucket. After the shard is stopped and the backup is uploaded, the shard will be deleted.

Update policyUpdate policy

• Minor updates (within the major version, e.g., 15.1 → 15.2) are installed automatically as part of maintenance performed during the maintenance window specified for the shard (PostgreSQL cluster), or at the customer's request. These updates contain security and bug fixes. A minor update requires a short, successive reboot of the cluster hosts.
• Major updates (changes of the major version, 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 shards still running versions with expired support (EOL), Managed Service for Sharded PostgreSQL initiates an automatic update.

1. Notification: Owners of shards based on Deprecated versions will get a series of official email notifications: the first one six 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 Sharded PostgreSQL begins the process of auto-updating shards that have not been updated by their owners.
3. Stopping as a final measure: If an automatic update is not possible, Managed Service for Sharded PostgreSQL will stop a specific shard. Before it stops, the final backup will be created and saved in the customer's bucket.
4. Data access: Once a shard is stopped, responsibility for the data passes to the client. 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 early upcoming update notifications:

• When switching to Deprecated (prohibits creating new shards).
• 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.