YugabyteDB LTS and STS Releases: Upgrade Planning and the PostgreSQL 15 Path

On 9 December 2026, the YugabyteDB v2024.2 LTS series reaches the end of its maintenance period, according to the release dates published in the project’s documentation source. v2024.2 is the last long-term support series based on PostgreSQL 11. Moving off it is not a routine rolling upgrade: it is a YSQL major upgrade to a PostgreSQL 15-based series, with its own prerequisites, restrictions and behaviour changes.

This article explains how YugabyteDB names and supports its release series, where each series stands on 23 October 2026, how to choose between the LTS and STS series, and how to plan both kinds of upgrade.

How YugabyteDB versions its stable releases

The release versioning page describes three kinds of release: stable with long-term support (LTS), stable with standard-term support (STS), and preview. Stable versions use the format YYYY.N.MAINTENANCE.PATCH. The first series of each year (.1) is STS and the second (.2) is LTS. Maintenance releases arrive roughly every one to two months and carry backward-compatible fixes.

The page summarises the support policy as follows:

• STS series receive maintenance updates for at least one year from the first release, then extended support for a further 180 days.
• LTS series receive maintenance updates for at least two years, then extended support for a further 180 days.
• During extended support, no new updates are made to the series; customers are directed to existing fixes or to upgrade.
• Preview releases are for development and testing only, and there is no migration path from a preview release to a stable release.

Two points matter for planning. First, these timelines are YugabyteDB, Inc.’s policy for its customers, and the page refers to the vendor’s support services agreement for the full terms. For teams running the open-source database without a vendor contract, the dates still mark when maintenance releases stop. Second, Bassirah is not a YugabyteDB, Inc. partner. Our independent support does not extend vendor maintenance or produce vendor fixes; upstream fixes follow the project’s timeline, as our open-source support model explains.

Where each release series stands on 23 October 2026

The dates below come from the release data file behind the documentation’s releases table, and the latest releases from the GitHub releases page.

Series	PostgreSQL base	First release	Latest release	End of maintenance	End of life
v2026.1 (STS)	15	29 June 2026	v2026.1.2.0, 22 September 2026	29 June 2027	29 December 2027
v2025.2 (LTS)	15	11 December 2025	v2025.2.7.0, 5 October 2026	11 December 2027	11 June 2028
v2025.1 (STS)	15	23 July 2025	v2025.1.4.0	23 July 2026	23 January 2027
v2024.2 (LTS)	11	9 December 2024	v2024.2.11.0, 25 August 2026	9 December 2026	9 June 2027

The PostgreSQL 15 features page confirms that YugabyteDB is based on PostgreSQL 15 from v2025.1 (stable), and that v2024.2 and earlier are based on PostgreSQL 11. v2025.1 has already left its maintenance period. The v2024.1 STS series reached end of life on 7 March 2026, according to the releases index.

Choosing a target: LTS or STS

The obvious instinct is to pick the newest series. The dates argue for a more careful look. v2026.1 is newer than v2025.2, but as an STS series it reaches end of life on 29 December 2027, earlier than v2025.2 on 11 June 2028.

Factor	v2025.2 (LTS)	v2026.1 (STS)
Maintenance window	Longer; fewer forced series changes	Shorter; plan the next series change within a year
Features	Mature series with many maintenance releases	Newer features; for example, the Voyager release notes list table inheritance as GA in v2026.1 and tech preview in v2025.2
Fits teams that	Upgrade a few times a year and value stability	Need a specific new capability and can upgrade on a shorter cycle

For most production estates we recommend v2025.2 as the default target, and v2026.1 only where a feature it brings is needed and the team accepts the cadence. Under the versioning policy, the next LTS series would be v2026.2; it was not listed on the releases pages on the research date, so plans should not depend on its timing.

Upgrades within the same PostgreSQL base

The Upgrade YugabyteDB guide describes rolling upgrades that replace binaries one node at a time while the cluster rebalances. You can move between stable series in one step, as long as both are based on the same PostgreSQL major version. Moving from v2025.1 to v2025.2 or v2026.1 is in this category.

The upgrade runs in phases. In the upgrade phase you upgrade YB-Masters, then YB-TServers. In the monitor phase you run workloads on the new binaries while features that change on-disk or network formats remain disabled; the guide recommends staying in this phase for no more than two days. You then either finalize, which promotes AutoFlags and upgrades the YSQL system catalog, or roll back. After finalizing, roll back is no longer possible; returning to the old version means restoring a backup taken on that version into another cluster.

The guide lists rules that often surprise teams:

• Upgrade to the latest maintenance release of the target series.
• Upgrades must go to a chronologically later release. A cluster on v2024.2.11.0, published 25 August 2026, can only move to a release published after that date.
• Delete point-in-time recovery snapshot schedules before upgrading, and recreate them after finalizing or rolling back. PITR cannot target a time before the upgrade.
• Backups taken on the new version, or during the upgrade, cannot be restored to the previous version.
• Universes on a deprecated operating system must update the OS before the next major release.
• pgvector users must follow specific steps, and tables with vector indexes may need recreating.

The guide also notes that if you upgrade to v2025.2 with the cost-based optimizer already enabled, auto analyze, bitmap scans and parallel append are enabled by default. The compatibility mode page adds that universes using Enhanced PostgreSQL Compatibility Mode get all its features enabled on upgrade to v2025.2. Plans can change as a result, so test the critical queries.

The PostgreSQL 11 to 15 upgrade path

Moving from v2024.2 to a PostgreSQL 15-based series is a YSQL major upgrade. The YSQL major upgrade page describes it as fully online, with reads and writes available throughout. The prerequisites are strict:

• The cluster must run v2024.2.3.0 or later; the documentation suggests first moving to the latest v2024.2 release.
• All DDL is blocked for the duration, except for temporary tables and materialized view refresh. Schedule schema changes before, and pause jobs that run DDL.
• Upgrade client drivers first; the documentation states that they work with both versions.
• Remove PITR configuration, drop pg_stat_monitor, and export and drop tables that use pgvector, then recreate them after finalizing.
• Clusters with dedicated YB-Master nodes need a temporary yugabyte_upgrade superuser.

A precheck confirms that the database contains no features removed in PostgreSQL 15: yugabyted upgrade check_version_compatibility for yugabyted deployments, or pg_upgrade --check for manual deployments. During the upgrade the universe runs in mixed mode, with PostgreSQL 11 and 15 processes side by side, controlled by the ysql_yb_major_version_upgrade_compatibility flag. The catalog is upgraded to the PostgreSQL 15 format before the YB-TServers move.

Roll back differs by method. The manual procedure includes a rollback phase. The yugabyted page is marked early access and states that yugabyted does not currently support rollback. Both pages note that backups taken during the monitor phase can only be restored to a PostgreSQL 15-compatible universe, and that you should run ANALYZE after the upgrade if you use the cost-based optimizer. Universes with change data capture through logical replication need extra steps, described on the logical replication upgrade page, which supports targets from v2025.1.1.

Behaviour changes to test before the major upgrade

The PostgreSQL 15 features page lists changes that can break clients or scripts:

• ysqlsh no longer accepts --c for --command.
• Queries without a space between a parameter and a keyword, such as $1ORDER, now fail to parse.
• clientcert=1 is no longer accepted in pg_hba.conf; use verify-ca or verify-full.
• The minimum TLS version default rises to TLS 1.2, so older drivers may fail to connect.
• From v2025.2, the default password encryption is scram-sha-256 instead of md5.
• New users no longer get CREATE on the public schema, and extra_float_digits changes how floats are printed.

Universes linked by xCluster

The upgrade guide sets an order for xCluster. For unidirectional replication, upgrade and finalize the target first, then the source, because the target must run the same or a later version. If the source is finalized first, replication pauses. For bidirectional replication, upgrade both, monitor both, and finalize both as close together as possible. The guide also asks some xCluster users to run a verification script for technical advisory TA-31533 before upgrading.

A planning sequence that works

1. Inventory every universe: series, exact version, OS, extensions, xCluster links and CDC streams.
2. Choose the target series per universe, using the support dates and feature needs above.
3. Bring v2024.2 universes to the latest v2024.2 release, then run the PostgreSQL 15 precheck and fix what it reports.
4. Test client drivers, TLS, authentication and critical queries against the target in staging.
5. Rehearse the full upgrade, including rollback where the method supports it, on a copy of production.
6. Agree a DDL freeze window, a backup taken before the upgrade, and a go or no-go decision point before finalizing.
7. Upgrade, monitor within the recommended window, finalize, recreate PITR schedules and run ANALYZE.

How Bassirah can help

Bassirah plans and runs YugabyteDB upgrades, including PostgreSQL 11 to 15 major upgrades, as independent engineering for self-managed universes. See our YugabyteDB practice and platform reliability work. Bassirah is not a YugabyteDB, Inc. partner; vendor support, YugabyteDB Anywhere and YugabyteDB Aeon are contracted with YugabyteDB, Inc.