Choosing a version, and the support calendar that decides it

Version choice for PostgreSQL is unusually easy to reason about, because the project publishes a schedule and keeps to it. Each major version is supported for five years from its initial release, and minor releases are issued on a quarterly schedule with out-of-cycle releases when a serious defect demands one.

What makes this worth a lesson is not the policy but what operators do with it. A database is the component of an estate most likely to be left on an old version, because upgrading it feels risky and nothing appears to be wrong. The support calendar is the instrument that turns that drift into a date somebody has to own.

The two kinds of version change

PostgreSQL version numbers since 10 are two-part: 18.6 is major version 18, minor release 6. The two move for entirely different reasons and cost entirely different amounts.

The asymmetry is the point. A minor update is a restart. A major upgrade is a project, and Part XVII is devoted to it.

Conflating the two produces a specific and common failure: a team that has correctly identified major upgrades as risky applies the same caution to minor updates, and the cluster sits on a release with known security fixes available for it, sometimes for years.

The current calendar

Read from the project’s versioning page on 2026-08-27:

PostgreSQL 19 was at Beta 3 on 2026-08-13 and is not production guidance. It is named here only because it is what the next major upgrade will eventually target.

Two things follow immediately from that table.

PostgreSQL 14 has weeks, not years. Its end of life is 2026-11-12. An estate still on 14 needs a dated upgrade plan now, and “we will look at it next year” is not available. After that date there are no further security fixes, so a vulnerability disclosed in December affects a cluster with no upstream remedy.

A new major appears every autumn. The pattern in the table — September or October each year — means the oldest supported version drops off at roughly the same time. An estate that adopts every second major version stays supported with an upgrade roughly every two years; one that adopts every fourth will be forced.

Reading the version of a running server

Three commands, answering three different questions.

# The full version string, including the packaging and build
psql -U postgres -tAc 'SELECT version()'

# The version as a number, for scripts and comparisons
psql -U postgres -tAc 'SHOW server_version_num'

# The version of the client you are using, which may differ
psql --version

$ psql -U postgres -tAc 'SELECT version()'

PostgreSQL 18.6 (Debian 18.6-1.pgdg13+2) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit

server_version_num is the one to use in automation. It encodes the version as an integer — 18.6 becomes 180006 — so a comparison is arithmetic rather than string parsing, and a check for “at least 17” is >= 170000 rather than an exercise in splitting on dots.

The client version is worth checking separately because it is frequently different from the server. A newer psql talks to an older server without difficulty, and the project supports that direction. The reverse — an old client against a much newer server — is where problems appear, and PostgreSQL 18 introduced one specifically worth knowing: \. is no longer treated as an end-of-file marker in COPY FROM for CSV files, which can affect \copy from older clients.

For an offline data directory, where there is no server to ask:

# The major version that owns this data directory
cat "$PGDATA/PG_VERSION"

# Rather more detail, if the matching binaries are available
pg_controldata "$PGDATA" | head -20

$ pg_controldata $PGDATA

pg_control version number:            1800
Catalog version number:               202506291
Database cluster state:               in production
Data page checksum version:           1

Assessing an estate

The output that matters to a manager is not a version list; it is a list of dates. This query, run across an estate, produces the raw material.

psql -U postgres -tAc \
  "SELECT current_setting('server_version') AS version,
          current_setting('server_version_num')::int AS version_num"

Turn that into a table with three columns per cluster: the version, the end-of-life date from the calendar above, and the number of months remaining. Anything under twelve months is a plan that needs an owner; anything under six is a plan that needs a date in a change calendar.

The second question to ask of every cluster is whether it is on the current minor. That is a much shorter conversation and a much cheaper fix, and it is where most estates have their real exposure.

Which version to choose for something new

For a new deployment the answer is usually the current major, and the reasoning is arithmetic rather than preference: choosing 18 in 2026 buys support until 2030, while choosing 17 to be conservative buys a year less and gains nothing that matters operationally.

The cases where the newest is not the right answer are specific and worth naming.

An extension you depend on does not yet support it. This is a real constraint and it is checkable in advance.

A managed service does not offer it yet. Cloud providers lag the upstream release, sometimes by a year, and this is not negotiable.

An existing estate runs an older major, and the operational cost of running two majors — two sets of binaries, two upgrade paths, two sets of monitoring caveats — exceeds the benefit for one new cluster.

Note what is not on that list: “the newest release is not mature yet.” A major version has been through beta and release-candidate cycles and receives its own minor releases from the day it ships. Waiting a few months for the first or second minor of a new major is a defensible mild caution; waiting years is how an estate ends up where PostgreSQL 14 users are today.

Production discipline

1. Run the current minor release for your major. Minor releases contain fixes only, so there is no feature-testing argument for delay, and 18.6 alone carried fixes for 28 security vulnerabilities.
2. Put the end-of-life date of every cluster in a calendar. The date is published years ahead and nothing surfaces it for you.
3. Use server_version_num in automation. Integer comparison beats parsing a version string, and 18.6 is 180006.
4. Check extensions, the operating system and the drivers before committing to a major upgrade date. Any one of them can turn a one-step upgrade into a two-step one.
5. Read PG_VERSION before touching an offline data directory. It tells you which major version can open it and therefore what to install.

Cross-course references

• Linux for Production Sysadmins — Part XI (Packages) and Part XXXII (Vulnerability management) cover the patching cadence this lesson asks you to put minor updates onto.
• Git, CI/CD & GitOps — Part CVI (Change management) covers recording an upgrade as a change with a rollback plan rather than as an event.
• Observability for Production Sysadmins — Part XCIII (Upgrades) covers keeping monitoring working across a version change, which Part XVII of this course treats as upgrade validation.

Quiz