Key Takeaways

•   PostgreSQL 12 reached end of life on November 14, 2024, and its final community release, 12.22, shipped a week later – no more security patches or bug fixes from the community.
•   The database keeps running after EOL, which is the problem: unpatched CVEs accumulate quietly until a compliance audit or exploit makes it urgent.
•   Your realistic options are upgrading to a supported release (18, 17, 16, or 15) or using vendor-backed or cloud-provider extended support to stay patched while you plan the migration.
•   Major PostgreSQL upgrades require real testing time – compatibility issues involving extensions and drivers usually create more work than the cutover itself.

Your PostgreSQL 12 instance didn’t crash on November 15, 2024. It probably didn’t even hiccup. And that’s the trap.

PostgreSQL 12 hit end of life on November 14, 2024. The community shipped one last out-of-cycle release, 12.22, a week later to fix a regression – and then closed the branch for good. The software still runs. Security and bug fixes don’t. Most teams quietly leave it in production and move on to more urgent work. Then, months later, a newly disclosed vulnerability turns out to affect the 12.x line, no community patch is coming, and a system that “worked fine” is suddenly carrying a known, unfixable flaw.

This guide covers what actually changed on that EOL date, what the real risks look like in practice, and what your options are for getting back to a patched state – including honest notes on where each path gets uncomfortable.

What Does PostgreSQL 12 End of Life Mean?

End of life means the PostgreSQL Global Development Group has shipped the final 12.x release and closed the branch. No security patches. No bug fixes. If a newly disclosed vulnerability affects PostgreSQL 12, it stays unpatched on the community side, permanently. An EOL database processing regulated data or supporting an internet-facing application becomes a growing liability every time a new flaw lands on its branch, because no community fix is coming.

Important PostgreSQL EOL Dates to Keep in Mind

The PostgreSQL project supports each major version for five years from its initial release, then ships one final minor release and calls it done. No separate “active” and “maintenance” tiers like Node.js LTS. It’s a single five-year window, and then the branch is retired.

Version	Released	End of Life	Status
18	Sep 2025	Nov 2030	Supported (latest)
17	Sep 2024	Nov 2029	Supported
16	Sep 2023	Nov 2028	Supported
15	Oct 2022	Nov 2027	Supported
14	Sep 2021	Nov 2026	Supported (ends soon)
13	Sep 2020	Nov 2025	EOL
12	Oct 2019	Nov 2024	EOL
11	Oct 2018	Nov 2023	EOL

If you’re on 12, you’re two major versions below the oldest supported branch. If you’re on version 13, you joined the EOL club in November 2025. Version 14 looks safe on paper, but its EOL lands on November 12, 2026 – closer than most people realize.

Why PostgreSQL Versions Are Retired

Retiring a major version isn’t the community being difficult. It’s a deliberate tradeoff that keeps the project healthy. A few forces drive it.

The five-year clock is fixed by design

PostgreSQL commits to five years of support per major version, counted from the initial release. That predictability is genuinely useful: you can look at any version and know its expiry date years in advance.

The catch is that the clock doesn’t care about your migration backlog. PostgreSQL 12 shipped in October 2019, so its November 2024 EOL was effectively locked in from day one. Teams that treated the date as “someday” found it arriving on schedule, as dates tend to do.

Maintaining old branches gets expensive

Every supported major version is a separate branch the maintainers have to patch, test, and release. Backporting a single security fix across five or six live branches is real engineering work, done by project contributors and the companies that sponsor them.

At some point the cost of keeping an old branch alive outweighs the benefit. Code paths diverge. Test infrastructure ages. A fix that’s straightforward on the current branch might require awkward surgery on a five-year-old codebase. Retiring the oldest branch lets the project put that energy toward the versions most people actually run.

Security backports have a shelf life

Some vulnerabilities are easy to patch on old code. Others depend on architecture that newer versions changed, and backporting those fixes to a much older branch can range from painful to genuinely risky. The backport itself might introduce regressions in code paths nobody has exercised in years.

Once a version is EOL, that backporting burden moves to you, or to whoever you pay to handle it.

Risks of Running an EOL PostgreSQL Version

The risks of staying on PostgreSQL 12 aren’t hypothetical. They compound the longer you wait.

Unpatched Security Vulnerabilities

Any vulnerability disclosed against PostgreSQL 12 after its EOL stays open on the community side, full stop. The out-of-cycle 12.22 release on November 21, 2024, was the last patch version 12 will ever receive – it shipped to fix a regression in 12.21, not to extend support. Anything disclosed after that either doesn’t affect 12, or affects it and will never see a community fix.

The broader trend makes this worse. Vulnerability trackers logged 16 PostgreSQL CVEs in the first half of 2026 – already more than in all of 2025 – with an average severity score above 7. The community’s May 2026 security release alone patched 11 vulnerabilities across the supported branches, with severity scores as high as 8.8. Not all of those affect version 12. The concern is what happens when a newly disclosed issue does: the community no longer produces a fix for it.

For additional details on protecting your environment against unpatched risks, you can learn more about PostgreSQL security best practices in our detailed guide. You can also explore PostgreSQL vulnerabilities and the security risks they can create in our in-depth guide.

This is the exact gap vendor-backed extended support exists to close. More on that in the options section below.

Compliance and Audit Failures

PCI DSS explicitly requires patching known vulnerabilities and tracking end-of-life technology in scope. HIPAA and SOC 2 don’t name EOL software outright, but assessors treat a database that can no longer receive security patches as a finding waiting to happen. Either way, “the vendor stopped patching it” is a hard position to defend, regardless of how locked-down the rest of your stack is.

Auditors check version support status directly – through questionnaires, vulnerability scans, and asset inventories. “We’re working on the upgrade” is not a strong answer when the EOL date passed in November 2024. Findings carry real costs: lost deals, remediation deadlines, and in regulated sectors, fines.

Ecosystem Drift

Security gets the attention, but the slower problem is everything around the database moving away from version 12. Extension maintainers stop testing against it. Client drivers drop support. Managed providers add extended-support surcharges, block new deployments, or schedule forced upgrades.

None of this is catastrophic on its own, but it accumulates. Eventually a library maintainer ships a release that assumes PostgreSQL 14+ behavior, or your monitoring integration deprecates 12.x support. You end up with a database you can’t safely touch and can’t easily leave.

Options After PostgreSQL 12 End of Life

You have four realistic moves. The right one comes down to risk tolerance: can you absorb the disruption of an upgrade now, or do you need to stay patched and compliant while you map out a stable migration path?

1. Vendor-backed Extended Support

If you can’t migrate immediately but also can’t sit on unpatched software, extended support is the bridge. A few vendors offer this. TuxCare’s Endless Lifecycle Support currently covers PostgreSQL 13, and the company has announced plans to add 14 before its EOL date.

The point of extended support isn’t to avoid upgrading forever. It’s to convert a hard deadline into a planned project. Instead of an emergency migration squeezed into a sprint between feature work, you get a patched instance and the breathing room to migrate when you’re ready rather than when a CVE or auditor forces your hand.

This option fits teams in regulated environments, those running heavily customized setups, or anyone whose realistic migration window is months out. It also gives you a documented patching path to show auditors while the actual upgrade is still in flight.

2. Upgrade to PostgreSQL 18

PostgreSQL 18 is the current release, supported through November 2030. Jumping straight to it gives you the longest runway before you’re doing this exercise again, plus the newest performance and feature work.

The tradeoff is distance: going from 12 to 18 spans six major-version jumps, which means more behavioral changes to verify at once – planner differences, deprecated settings, and extension compatibility across the board. Use pg_upgrade (with the new version’s binaries installed alongside the old) rather than a full dump-and-restore, but budget serious staging time:

pg_upgrade \

  –old-datadir /var/lib/postgresql/12/main \

  –new-datadir /var/lib/postgresql/18/main \

  –old-bindir /usr/lib/postgresql/12/bin \

  –new-bindir /usr/lib/postgresql/18/bin \

  –check

Paths shown are Debian/Ubuntu defaults – adjust for your distro. Run it with –check first: it surfaces many blockers before you commit to anything, though it won’t catch every application-level or performance issue.

3. Upgrade to PostgreSQL 17, 16, or 15 (Still Supported)

If 18 feels like too big a leap, PostgreSQL 17 (EOL November 2029), 16 (EOL November 2028), and 15 (EOL November 2027) are all still community-supported and closer to 12’s behavior. Many teams target one of these as a deliberate middle step: enough support life to matter, fewer surprises than the latest release.

Keep the calendar in mind, though. Choosing 15 in 2026 buys you barely a year and a half before you’re back in EOL planning – 17 or 16 gives the middle-step strategy actual room to breathe. Picking one of these over 18 makes sense when your extensions haven’t certified against the newest version yet, or when you prefer a release with a longer production track record.

Pro Tip: Run SELECT * FROM pg_extension; on your live 12.x instance before picking a target, then check each extension against the candidate version. Extensions, not core PostgreSQL, are usually where upgrades stall mid-project.

4. Managed Cloud Extended Support

If you use Amazon RDS, Google Cloud SQL, or an eligible Azure Database for PostgreSQL deployment, your provider may offer paid extended support for certain EOL versions – availability and enrollment rules vary by service and version. Amazon RDS moved PostgreSQL 12 into RDS Extended Support after its standard-support period ended on February 28, 2025, with per-vCPU surcharges. Google Cloud SQL began charging extended-support fees for EOL major versions on May 1, 2025. Azure now enrolls servers on unsupported versions into Extended Support automatically, with billing for version 13 starting August 1, 2026.

This gives you provider-managed security updates without maintaining your own PostgreSQL backports, which is genuinely useful. The surcharges escalate over time, though – AWS’s rate steps up after the first two years – so treat it as a metered grace period, not a long-term strategy. Read the per-instance pricing carefully before assuming it’s the cheap option.

Here’s the decision in one view:

If your situation is…	Best move
Can’t migrate soon, need to stay patched and compliant	Vendor-backed extended support (e.g., TuxCare’s Endless Lifecycle Support)
Ready to migrate, want the longest support runway	Upgrade to PostgreSQL 18
Ready to migrate, want fewer surprises	Upgrade to 17 or 16
On managed cloud, buying short-term breathing room	Provider extended support

Planning the Migration Before It Gets Urgent

The teams that handle EOL well treat it like any other scheduled project. The ones that struggle tend to treat the EOL date as the moment to start thinking about it, which is roughly a year too late.

A workable migration plan usually covers:

•   Inventory. Every 12.x instance, including the forgotten replica and the analytics box nobody owns.
•   Dependency audit. Extensions, client drivers, ORMs, and replication tooling, each checked against your target version.
•   A target version decision. Chosen on extension compatibility and support runway, not gut feel.
•   A tested upgrade path. pg_upgrade, or logical replication for near-zero downtime, rehearsed in staging before you touch production.
•   A patching bridge. How you stay secure between now and migration day. That often means vendor or cloud extended support; documented compensating controls are the thinner alternative.
•   A rollback plan. Because something will surprise you, and you want an exit that isn’t “restore from last night’s backup.”

Reality Check: Vendors love calling major upgrades “painless.” They’re not. Even a clean pg_upgrade run leaves you re-validating extensions, re-tuning configs, and watching query plans shift. For a production environment with meaningful dependencies, plan for weeks of testing, not just a maintenance window.

What to Do If PostgreSQL 12 Is Still in Production

PostgreSQL 12 isn’t going to stop working, which is exactly why it’s easy to ignore until a CVE or an audit makes it urgent. The honest takeaway: decide on purpose. Upgrade to a supported release if you can move. If you can’t, get patching coverage in place so “not yet” doesn’t drift into “exposed for a year.”

On the extended-support side, TuxCare covers version 13 today if you need a commercial patching option while you plan the upgrade, with version 14 coverage announced ahead of its EOL. Verify exact version coverage with any vendor before treating extended support as your bridge.

Start by mapping your 12.x footprint: how many instances, which extensions, what depends on them. That inventory alone usually clarifies which path makes sense. The worst outcome is the one where you never chose at all.

FAQs