PostgreSQL 10.23 is the end of the supported 10 branch

A final maintenance release still repairs a database, but it changes what an administrator can expect afterward. PostgreSQL 10.23 contains fixes for vacuuming and recovery among other corrections. Installing it brings a version 10 installation to the branch's final published state. It does not provide a route to future fixes within that major version.

The November 10 release announcement identifies 10.23 as the final PostgreSQL 10 release. The branch will no longer receive security or bug fixes. Other supported branches receive updates in the same announcement, including 15.1 and 14.6. The important distinction for a version 10 deployment is between applying its last maintenance update and migrating to a branch that continues to receive maintenance.

I default to PostgreSQL for relational work partly because its operating behavior is documented in detail. That expectation includes treating support status as a property of the deployed major version. A database can remain operational while the upstream branch maintaining its implementation has closed.

The final update still addresses correctness

The 10.23 release notes describe a vacuum repair involving B-tree page deletion. When an attempted deletion cannot find the parent downlink, vacuum now logs the problem and continues without deleting the empty page. Previously the error could indefinitely prevent vacuuming from completing, eventually contributing to transaction wraparound problems.

The underlying problem can involve a corrupted index or a faulty operator class. Continuing does not mean that the index problem has vanished. It means maintenance can avoid letting one failed page-deletion attempt prevent all further progress. That is a useful distinction between repairing a specific maintenance failure mode and declaring the affected structure healthy.

Another fix concerns promotion after archive recovery outside standby mode. If the last WAL segment read ended with a partial record, the promoted instance could write an invalid WAL segment on its new timeline. The release repairs that sequence. Recovery behavior is therefore part of the final branch state, even though the headline is end of support.

These entries give a concrete reason to regard 10.23 as more than an administrative marker. It includes changes to what happens when cleanup or recovery reaches a difficult condition. The end-of-life announcement does not make those changes irrelevant to installations that still need a migration interval.

A maintenance update preserves the data format

The upgrade documentation shipped with PostgreSQL 15.1 explains the difference between minor and major versions. Minor versions retain the internal storage format. Updating within one major version involves replacing executables while the server is stopped and restarting against the existing data directory.

That is the kind of update represented by 10.23. Its notes do not require a dump and restore for an existing 10-series installation, while directing users skipping older updates to inspect the relevant earlier notes. The operation repairs the branch implementation without changing the installation into another major version.

Moving from 10 to a newer major version is a different operation. Major versions can change internal storage and introduce user-visible incompatibilities. Installing a newer executable over the old one does not make the existing data directory suitable for that version. PostgreSQL documents data migration methods for crossing that boundary.

This distinction is especially important when an end-of-life notice appears inside a routine update announcement. The familiar maintenance procedure remains valid for installing the final patch. Continuing upstream support requires another step with a different technical scope.

Logical migration reconstructs the database

One documented route is a logical dump and restore. The upgrade chapter recommends the newer version's dump tools and explains that a filesystem-level backup is not a substitute for logical export when moving between incompatible major versions. The dump describes database contents in a form that the destination can recreate.

A consistent dump also has a time boundary. Changes made after it begins are not included in that exported view. The upgrade instructions therefore address stopping updates when taking the final migration backup. Consistency of the backup does not mean it includes writes that happen later.

Logical reconstruction can take time, particularly when the destination must recreate a large amount of data. The same chapter describes running old and new installations on separate ports while transferring data. That arrangement makes the destination distinct and allows the old installation to remain available during preparation. The final application handover still needs a defined point after which new writes belong to the destination.

I find that distinction useful because it connects downtime to a mechanism. Exporting and restoring data has one cost, while coordinating the final writes has another. Merely naming dump and restore does not describe the application's handover behavior.

Other upgrade methods change the work involved

PostgreSQL also documents pg_upgrade as a way to migrate between major versions without the same logical reconstruction process. Its procedure still includes initialization and server start or stop steps. It is a different data-migration tool, not permission to start a new major server directly on an arbitrary old data directory.

Logical replication provides another documented route. It can move changes between different PostgreSQL major versions, letting a newer instance catch up before switching the application. That changes how much data work occurs before the handover. The method still depends on the replication arrangement covering the data and operations the application needs.

A direct move can skip intervening major installations, but the upgrade documentation says to read the release notes of the intervening major versions. Skipping their binaries does not skip their accumulated behavior changes. Application SQL and administrative tooling may depend on behavior that changed somewhere between the source and destination.

The end of PostgreSQL 10 support therefore creates two distinct pieces of work. Version 10.23 supplies the final corrections available on the existing branch. A major-version migration establishes a destination that can receive subsequent upstream fixes, using a data-transfer method and application handover appropriate to that installation.