On 12 November, PostgreSQL 14 gets its final minor release and the branch is left without security patches. What follows forks depending on where that database lives: some people will find out through a new charge on their bill, and others won't find out at all.
The policy is public, and has been written for years
PostgreSQL supports each major version for five years after its initial release. After that, in the literal words of its policy: "a final minor version will be released and the software will then be unsupported (end-of-life)". There is no grey zone and no extended support from the project: there is a date, and after it no more security patches ship for that branch.
That same table already has the next four dates written down:
| Major version | Final minor release |
|---|---|
| PostgreSQL 14 | 12 November 2026 |
| PostgreSQL 15 | 11 November 2027 |
| PostgreSQL 16 | 9 November 2028 |
| PostgreSQL 17 | 8 November 2029 |
| PostgreSQL 18 | 14 November 2030 |
It's a four-year calendar, published, that almost nobody has copied into their own. Something similar is happening this month on another front: the same thing happening to Zabbix 7.4 this month, though there the mechanism is losing full support rather than a final minor release.
Two roads from the same end-of-life
The same end-of-life produces two completely different things depending on where the database is running.
If it's managed: the date turns into money
Managed providers don't switch your database off when the version expires. They leave it running and charge you for it. On Amazon RDS it's called Extended Support and, per their own documentation, it "will be a separate sku/line item on your bill, i.e. you will pay for Amazon RDS Extended Support in addition to your database/storage/backup charges".
The example AWS publishes on its own pricing page, for PostgreSQL 12 in the Ohio region, is $0.100 per vCPU-hour for the first two years and $0.200 from the third. The rate depends on region and date, so that number isn't universal; the mechanism is. Running the numbers on a modest 4 vCPU instance: $0.400 an hour, $3,504 a year, and $7,008 once year three kicks in. On top of what you already pay.
For anyone who had already negotiated their budget: "RI discounts do not apply to Amazon RDS Extended Support" — though AWS goes on to say "your unique custom discounted terms may apply" and points you at your account team. In practice: the three-year commitment discount doesn't touch this line; if you have separately negotiated terms, that needs confirming.
An honest caveat, because it matters: the figures above are the published example for version 12 in one specific region, and RDS runs its own calendar, not the community's. Extended Support starts the day after that version ends standard support on RDS, which needn't be 12 November. If you have 14 on RDS, the date that applies to you is on their calendar, not PostgreSQL's.
If it's yours: the date turns into nothing
On your own server — a virtual machine, a container, a Debian package — absolutely nothing happens on 12 November. No bill, no warning, no email from a provider, no box turning red. The process keeps listening on 5432 and answering just as fast. The only thing that has changed is invisible: from that day on, when a security flaw turns up in that branch, there will be no patch.
The cloud charges you and, by charging you, tells you. Your own server doesn't charge you, and precisely for that reason it never tells you. Of the two, the one in worse shape is the second — even though it's the one that looks free.
And on top of that, you didn't choose that version
In Stack Overflow's 2026 developer survey, PostgreSQL is the most used database: 57.9% of the 12,061 answers to that question, against 42.1% for SQLite and 35.1% for MySQL. For maintenance purposes something else matters: a good share of those installations were not put there by a database administrator. They arrived inside something else.
Places where, in our experience, a PostgreSQL shows up that nobody installed on purpose:
- ·Underneath the network inventory tool. We run NetBox as our source of truth, and NetBox sits on PostgreSQL.
- ·Underneath monitoring and the deployment platform: Zabbix and GitLab can keep their state there, as can much of the CI fabric.
- ·Inside a vendor application that was installed turnkey and nobody has opened since.
- ·In an
image: postgres:14line in a compose file written three years ago, still deploying identically every time someone rebuilds the environment.
In all four cases someone else chose the version, years ago, and the five-year clock was already running then. Which is why the useful question today isn't "when do I upgrade?" but "how many PostgreSQL instances do I have, and what version is each one on?". If that takes more than ten minutes to answer, that is the real work, and it doesn't start on 12 November.
When paying for extended support is the right call
Sometimes paying is the right answer. A major version jump in PostgreSQL is not an apt upgrade. You go through pg_upgrade or a dump and restore, review the extensions (which move on their own schedule and sometimes have no compatible release yet), check that query plans don't regress, and rehearse the way back. That isn't an afternoon's work.
If the jump lands on top of year-end close, a seasonal peak or another migration already under way, deliberately buying a year of extended support is a defensible call: $3,504 is far cheaper than a restore nobody had rehearsed. What isn't defensible is paying it without having decided to, finding out three months later while reviewing the bill, and the version still being the same.
The migration is also when you get to review the "temporary" permissions set up years ago to run the backup or the replica. We've already covered how PostgreSQL's replication permission was never read-only; a version change is a good moment to fix it.
What we'd do this week
- 1.Count them. A
SHOW server_version;on every instance you know how to reach, plus a pass over the images of whatever containers are deployed. The number that comes out is almost never the one people expected. And next to each one, note where it came from: the distribution's repository, PostgreSQL's own repository, or inside a product. That determines who upgrades it and on whose calendar, which needn't be the community's. - 2.Separate the ones that aren't yours. The ones inside a vendor application aren't yours to upgrade: the vendor does it, and you need to ask with which product release and on what timeline. That answer in writing is worth more than the patch.
- 3.Look at the bill before it arrives. If anything is managed, find its support calendar and see the exact day the charge starts. It's the only one of the three with a hard date and a number on it.
None of this is hard. It's boring, which is different, and that's why it goes undone until the version has gone two years without patches or until someone in finance asks what that new line is. At everyWAN this falls under data and applications and, when the decision is upgrade-or-pay, under consulting: we don't resell any of these platforms, so the recommendation doesn't change our invoice.
Sources (verified 1 Nov 2026): versioning policy and final minor release dates for branches 14 to 18 — postgresql.org/support/versioning. Extended support mechanics and billing, including the sentence about reserved instance discounts — AWS Cloud Financial Management; example rate (PostgreSQL 12, US East Ohio) — Amazon RDS for PostgreSQL pricing page. PostgreSQL usage share — Stack Overflow 2026 developer survey. What is our own arithmetic: the $3,504 and $7,008 per year come from multiplying the published rate by 4 vCPU and 8,760 hours; anyone can repeat it with their own vCPU count. What we are not claiming: we give no end-of-standard-support date for PostgreSQL 14 on RDS or any other managed service, because each provider publishes its own calendar and it has to be checked; and the observation about where PostgreSQL turns up without anyone installing it is our own field experience, not a survey figure.
How many PostgreSQL instances do you have, and on what version?
If that takes more than ten minutes to answer, the problem isn't 14: it's the inventory. We build the list, separate what you upgrade from what your vendor upgrades, and tell you whether jumping now or paying for a year makes more sense in your case. We don't resell any of them, so whichever you choose is the same to us.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN