PostgreSQL 14 End of Life on 12 November 2026: An Upgrade Plan for Small Teams

PostgreSQL 14 end of life is set for 12 November 2026. That is the date of its final release, after which the PostgreSQL Global Development Group stops shipping fixes for it altogether, security fixes included. If your application still runs on 14, you have a hard deadline rather than a vague one, and the clock is already down to a few weeks.

The PostgreSQL project publishes its own versioning policy at postgresql.org/support/versioning, and it is worth checking that page directly before you plan anything, since release dates occasionally shift and you want the current number, not whatever this post says next year. As of this writing it lists PostgreSQL 14 as reaching end of life on 12 November 2026, five years after its initial release, which matches the project's usual pattern of supporting each major version for five years.

What PostgreSQL 14 end of life means for your database

PostgreSQL ships a new major version every year and supports each one for five years from its first release. During that window, minor releases land roughly every three months with bug fixes and security patches, no new features. Once the five years are up, that stops. There are no more minor releases and no more patches, including for vulnerabilities discovered afterward.

This is different from a deprecation warning. A vulnerability found in PostgreSQL 14 in December 2026 will get fixed in 15, 16, 17, and 18, and nothing will fix it in 14. If your database is reachable from the internet, or even just reachable from application code that handles untrusted input, that is a real exposure, not a theoretical one.

Checking which version you are running

This takes one command. Connect to your database and run:

SELECT version();

Or from the command line:

psql -c "SELECT version();"

If you are not sure how to connect, ask whoever manages your infrastructure, or check your hosting provider's dashboard. Most managed database services (RDS, Cloud SQL, Azure Database for PostgreSQL, DigitalOcean, Heroku's successors) show the running version directly in their console, and some of them have already started emailing customers about the 14 deadline.

If the answer comes back 14.x, you are affected, and the rest of this post is for you. If it comes back 13 or earlier, you are already past end of life and should treat this as more urgent, not less. If it comes back 15 or newer, you are fine for now.

Picking a target version: 17 or 18

Once you know you need to move, the next question is where to move to. PostgreSQL 18 is the current release as of late 2026, and 17 is the one before it. Either is a reasonable landing spot for a small team weighing effort against runway.

Moving to 17 gets you the smaller jump from 14, since it predates 18's changes to I/O and the addition of native UUIDv7 generation. If your application or its dependencies have not been tested against 18 yet, or you would rather make one upgrade now and a second one next year, 17 is the safer choice. Moving straight to 18 buys more years before you have to do this again and gives you the newer features if you expect to use them, at the cost of a slightly less tested path for some third-party tools. For most small applications doing standard CRUD work, the practical difference between the two targets is small; the honest answer is that either one gets you off an unsupported version, and the choice mostly comes down to how recently your extensions and ORM have confirmed support for 18.

Whichever you pick, do not try to skip straight past a check of your extensions first. PostgreSQL's own upgrade tooling handles the core database correctly, but extensions are a separate concern.

Extension checks before you touch anything

If your database uses pgvector, PostGIS, or any other extension, check its compatibility with your target version before you start, not after. Both of these are actively maintained and generally keep pace with new PostgreSQL releases, but "generally" is not "always," and running a version mismatch between PostgreSQL and an extension can mean anything from a failed ALTER EXTENSION UPDATE to binary incompatibility that silently returns wrong results.

The practical check is short: look up the extension's own release notes or GitHub repository, find its latest version, and confirm it lists support for the PostgreSQL version you are targeting. If you installed it through your package manager or a managed service, check what version that service currently makes available for 17 or 18 before you commit to an upgrade date, since some providers lag the extension maintainers by a few weeks.

Three upgrade routes, and what they cost in downtime

There is no single right way to upgrade PostgreSQL. The right route for a small team depends mostly on how much downtime you can tolerate and how large your database is.

pg_upgrade is the standard tool for this and the fastest option for most small to medium databases. It upgrades the data files in place rather than dumping and reloading every row, and with the --link option it can finish in minutes even for databases in the tens of gigabytes, because it is relinking files rather than copying them. The catch is that it still requires downtime: your application cannot write to the database while the upgrade runs, and you should plan for a maintenance window even if the tool itself is quick, since you also need to stop the old server, run the upgrade, verify it worked, and start the new one. For a small application, that usually means a window measured in minutes, not hours, but it is still a window your users notice.

Dump and restore using pg_dump and pg_restore is the simplest conceptually and the slowest in practice. You export the entire database to a file, then load it into a freshly installed version of PostgreSQL. This works reliably and gives you a clean copy to test before cutting over, but the dump and restore time scales with database size, and for anything beyond a few gigabytes you are looking at downtime measured in hours rather than minutes. It is a reasonable choice for small databases or as a fallback if pg_upgrade runs into trouble, but it is rarely the first choice once your data set has any real size to it.

Logical replication is the route that gets you close to zero downtime, at the cost of more setup work. You stand up a new server on the target version, replicate data to it continuously while the old server keeps serving traffic, and only cut over once the new server has caught up. The cutover itself still involves a brief pause to redirect traffic and confirm the last transactions replicated, but that pause is measured in seconds, not minutes. This is the right choice if your application genuinely cannot tolerate a maintenance window, but it adds real complexity: you need to handle sequences, large objects, and any DDL changes carefully, and it is worth a trial run on a copy of production before you do it for real.

For most small teams running an application that can tolerate a short planned outage, pg_upgrade is the pragmatic default. Save logical replication for cases where a maintenance window is genuinely not an option, and dump and restore for databases small enough that the slower approach does not matter.

What managed providers charge once you miss the deadline

If your database runs on a managed service like Amazon RDS, Google Cloud SQL, or Azure Database for PostgreSQL, missing the end of life date does not mean your database stops working. It means you move onto that provider's extended support tier, which exists precisely for customers who have not upgraded yet. AWS, for example, charges an additional hourly fee per vCPU for databases running on an unsupported major version under RDS Extended Support, on top of your normal instance cost, and that fee is explicitly designed to be less attractive than just upgrading.

These fees vary by provider and change over time, so check your specific provider's current pricing page before assuming a number, but the pattern across providers is consistent: extended support costs more than staying current, often noticeably more, and it is meant as a short bridge rather than a long-term plan. If your application is still on PostgreSQL 14 past 12 November 2026 for business reasons you cannot avoid, budget for that extra line item and set an internal deadline to get off it within a few months, not a few years.

A one-page upgrade plan you can hand to management

If you need to get budget or a maintenance window approved, here is the version a non-technical manager can act on without reading the rest of this post:

PostgreSQL 14, which our application runs on, stops receiving any fixes, including security fixes, after 12 November 2026. We need to move to a newer supported version before that date, or accept a rising extra fee from our hosting provider if we miss it. The work itself is a planned upgrade with a short maintenance window, typically minutes for a database our size, during which the application will be briefly unavailable. We will test the upgrade on a copy of the database first, confirm our extensions still work on the new version, and schedule the real cutover for a low-traffic time. Once done, we gain roughly [two to five] more years of support, depending on which version we land on.

Fill in the bracketed detail with the actual gap between today and your chosen target's own end of life date from postgresql.org/support/versioning, and you have something concrete to put in front of whoever signs off on the downtime window.

Where this fits into ongoing maintenance

An end of life deadline like this one tends to arrive as a surprise only when nobody is tracking version support dates as a routine matter. We have written about building a yearly checklist for exactly this kind of deadline, so PostgreSQL 14 is the last version that catches your team off guard rather than the next in a series.

If the upgrade itself needs to happen without taking your application offline for an extended window, our post on database migrations on live systems covers the expand and contract patterns that make that possible for schema changes running alongside a version upgrade.

If you would rather have someone else confirm your current version, check your extensions, and run the upgrade for you, that is exactly the kind of work our Code Readiness Sprint covers in one to two weeks, or we can fold it into an ongoing maintenance retainer so deadlines like this one get handled before they become urgent. Reach out at hello@wolf-tech.io or visit wolf-tech.io to talk through your specific setup.