PostgreSQL 11, 12, and 13 End of Life: What Enterprises Need to Know

PostgreSQL's Support Lifecycle

PostgreSQL follows a strict and predictable 5-year support lifecycle. Each major version receives security patches, bug fixes, and minor releases for exactly five years from its initial release. After that date, the PostgreSQL Global Development Group stops backporting fixes to that version.

The EOL dates for recent major versions:

• PostgreSQL 9.6: November 2021
• PostgreSQL 10: November 2022
• PostgreSQL 11: November 2023
• PostgreSQL 12: November 2024
• PostgreSQL 13: November 2025
• PostgreSQL 14: November 2026 (approaching)
• PostgreSQL 15, 16, 17: Currently supported

What Happens After the EOL Date?

After the EOL date, PostgreSQL stops publishing minor version releases for that major version. CVEs disclosed against that version receive no official fix. This is not a theoretical concern: PostgreSQL continues to receive CVE disclosures on a regular cadence. CVE-2026-1093, a row security policy bypass with a CVSS score of 8.5, was disclosed affecting PostgreSQL 11–13 after PostgreSQL 11 had already reached community EOL. There was no official patch available for PostgreSQL 11.

For enterprises, this creates both a security gap (a known exploitable vulnerability) and a compliance gap (SOC 2, PCI DSS, HIPAA, and other frameworks require that software be protected against known vulnerabilities).

Why Haven't Most Enterprises Migrated Already?

PostgreSQL major version upgrades — unlike minor version patches — are potentially disruptive. The process typically involves:

1. Pre-migration assessment: Auditing the schema for deprecated features, functions, or behaviors that changed between versions. PostgreSQL 11 to 16 spans several behavioral changes in query planning, partitioning, and transaction handling.
2. Extension compatibility: PostGIS, pgvector, TimescaleDB, Citus, and other commonly used extensions must each be tested for compatibility with the target major version.
3. Application testing: ORM behavior, connection pooling configuration, query planner hints, and stored procedure behavior can all differ between major versions.
4. Data migration: Using pg_upgrade for in-place upgrades or logical replication for rolling upgrades. Both require careful execution for large databases (multi-terabyte) or complex HA setups.
5. Downtime or cutover planning: For mission-critical workloads, even a 15-minute maintenance window requires executive approval and change control processes.

For a bank running PostgreSQL 12 across 40 production databases with a custom Patroni HA setup, "just upgrade" is a 6-month project, not a weekend task. EOL dates don't align with organizational planning cycles.

The Compliance Risk Is Real and Immediate

Regulated industries face direct audit consequences from EOL PostgreSQL:

• PCI DSS: Requirement 6.3.3 requires all system components to be protected against known vulnerabilities. A PostgreSQL 11 installation with disclosed CVEs has no compliance defense without a patch or compensating control.
• OCC/FFIEC examination: Federal bank examiners have begun citing EOL database versions as technology risk findings in technology examinations. The finding is documented in the examination report and requires a remediation timeline.
• HIPAA: The Technical Safeguards standard requires that ePHI systems implement protection against known vulnerabilities. EOL PostgreSQL handling PHI is a reportable finding under a HIPAA technical audit.
• SOC 2 Type II: CC7.1 requires the organization to detect and monitor threats, which includes known CVEs on production systems.

What Are Your Options?

Migrate to PostgreSQL 15 or 16

The permanent fix. PostgreSQL 15 introduced significant improvements in logical replication, partitioning performance, and security. PostgreSQL 16 added further query parallelism improvements and libpq connection security options. Migrating to PG 16 gives you a version supported through November 2028.

Extended lifecycle support

OSSeva delivers backported CVE patches for PostgreSQL 11, 12, and 13. Each patch delivery includes the patched binary, regression test evidence, and a CVE attestation letter documenting the vulnerability addressed, the CVSS score, affected versions, and OSSeva's fix. These documents are designed for direct submission to auditors and are accepted by OCC examiners, QSAs, and HIPAA auditors as third-party assurance evidence.

Document and accept the risk

Formal risk acceptance — documented, approved at the appropriate level, with a defined remediation timeline — is sometimes the right short-term answer. However, "we're aware of the risk" without an active compensating control (patching) rarely satisfies a regulator in a formal examination.

High-Availability Considerations

Most enterprise PostgreSQL deployments run Patroni or repmgr for high availability, with PgBouncer for connection pooling. Extended lifecycle patches are tested against these configurations. OSSeva's Patroni-compatible patches are validated against both synchronous and asynchronous standby configurations before delivery.