← Back to all briefings
Developer 6 min read Published Updated Credibility 40/100

Developer Platform Briefing — September 15, 2025

PostgreSQL 13 reached its end-of-life on 13 November 2025, leaving organisations without coordinated security updates. This briefing explains PostgreSQL’s five‑year support policy, summarises what version 13 introduced, highlights major improvements in subsequent releases such as 15 and 16, outlines the risks of running unsupported databases, and provides a roadmap for migrating to supported versions like 16.

Zeph Tech Research Lead

Research lead, Zeph Tech

Timeline plotting source publication cadence sized by credibility.
4 publication timestamps supporting this briefing. Source data (JSON)

Executive summary. PostgreSQL is an enterprise-grade relational database that releases a new major version approximately once a year. Under the PostgreSQL Global Development Group’s versioning policy, each major release receives bug fixes and security updates for five years【739429032173515†L36-L38】. PostgreSQL 13, first released on 24 September 2020, made significant performance gains—such as B‑tree index de‑duplication, improved query planning for aggregates and partitioned tables, and incremental sorting【724113118764390†L39-L52】. The final minor release, version 13.23, arrived on 10 November 2025, and community support ended on 13 November 2025【739429032173515†L76-L83】. Organisations still running 13.x after that date lose access to coordinated security patches, leaving them exposed to vulnerabilities like the privilege escalation flaw CVE‑2024‑4317. This briefing explains why upgrading is essential and offers guidance on planning migrations to PostgreSQL 15 or 16.

Support lifecycle and end‑of‑life schedule

PostgreSQL’s versioning policy guarantees each major release five years of support【739429032173515†L36-L38】. During that window, the project issues quarterly minor releases that include bug fixes and security patches【739429032173515†L26-L30】. After the five‑year window, a final minor release is published and the version becomes “unsupported.” Version 13’s five‑year window closed on 13 November 2025【739429032173515†L76-L83】. The project encourages users to upgrade directly to any supported major version; a dump/restore via pg_dumpall, the pg_upgrade tool or logical replication is required because major releases are not in‑place compatible【739429032173515†L52-L60】. Upgrading skips intervening versions, but reading the release notes of each intervening release is recommended【739429032173515†L59-L60】.

What PostgreSQL 13 introduced

Although version 13 is now end‑of‑life, understanding its features helps teams evaluate changes in later releases. Key highlights included:

  • B‑tree index de‑duplication: Version 13 implemented de‑duplication of B‑tree index entries, resulting in space savings and performance gains【724113118764390†L39-L45】.
  • Improved aggregate and partitioned table performance: The release improved performance for queries using aggregates and partitioned tables【724113118764390†L41-L45】.
  • Enhanced query planning: The planner made better use of extended statistics, producing more efficient execution plans【724113118764390†L45-L47】.
  • Parallelized vacuuming: Version 13 parallelized vacuum operations on indexes, reducing maintenance overhead【724113118764390†L48-L50】.
  • Incremental sorting: The introduction of incremental sort improved query performance for large datasets【724113118764390†L49-L52】.

These improvements made PostgreSQL 13 a robust platform. However, the pace of innovation in subsequent releases means version 13 no longer reflects the state of the art.

Why upgrade? Highlights from PostgreSQL 15 and 16

Newer major releases provide compelling reasons to move beyond version 13:

  • SQL MERGE and replication enhancements (v15): PostgreSQL 15 added native support for the MERGE statement【838635252427439†L35-L40】, selective publication of table contents for logical replication【838635252427439†L39-L41】 and Zstandard (zstd) compression for backups【838635252427439†L43-L47】. It also introduced structured JSON logs and improved in‑memory and on‑disk sorting performance【838635252427439†L47-L50】.
  • Performance and replication improvements (v16): PostgreSQL 16 introduced extensive query planner optimisations, including parallelising full and right joins and improving DISTINCT queries【653419441010974†L63-L69】. Bulk data loading saw performance increases of up to 300 %【653419441010974†L72-L74】, and the release added CPU‑accelerated string processing and new I/O monitoring metrics【653419441010974†L72-L79】【653419441010974†L123-L129】. Logical replication can now originate from standby servers【653419441010974†L81-L88】, and new SQL/JSON syntax and developer conveniences enhance productivity【653419441010974†L105-L117】.
  • Access control and security enhancements: PostgreSQL 16 provides finer‑grained access control options, introduces require_auth for specifying acceptable authentication methods and supports Kerberos credential delegation【653419441010974†L136-L149】. These features strengthen database security, reducing reliance on external tools.

In addition to functional improvements, adopting a supported version ensures timely fixes for vulnerabilities, optimised performance on modern hardware and compatibility with evolving ecosystem tools (e.g., ORMs, drivers, replication frameworks).

Risks of staying on an unsupported version

Running PostgreSQL 13 beyond its end‑of‑life exposes databases to significant risks:

  • Absence of security patches: Once community support ends, there are no coordinated releases addressing new vulnerabilities. Privilege escalation vulnerabilities like CVE‑2024‑4317 highlight how quickly critical flaws can emerge.
  • Compliance and audit failures: Many regulatory frameworks (e.g., SOC 2, ISO 27001) require running supported software. Auditors may flag unsupported databases as non‑compliant, jeopardising certifications.
  • Vendor support issues: Cloud providers and vendors (e.g., Amazon RDS, Azure Database for PostgreSQL) enforce upgrades shortly after EOL. Running unsupported versions may incur premium support fees or service disruptions.
  • Incompatibility with new tooling: Ecosystem tools drop support for out‑of‑date major versions. Staying on PostgreSQL 13 may prevent using new features in ORMs, backup utilities and monitoring systems.

Upgrade planning checklist

Successful migrations require careful preparation:

  1. Inventory databases and dependencies: Map all PostgreSQL 13 instances, including containerised services, embedded databases in applications and replicas. Identify dependent extensions such as PostGIS or logical replication plugins to verify compatibility.
  2. Assess workload characteristics: Capture baseline performance metrics (query plans, index usage, vacuum statistics) to compare after the upgrade. Document workload patterns and critical SLAs.
  3. Select target version: Evaluate whether PostgreSQL 15, 16 or 17 best fits your organisation. Consider support timelines (each gets five years) and specific features required (e.g., logical replication on standbys in v16).
  4. Test upgrade paths: Use staging environments to experiment with pg_upgrade, dump/restore or logical replication. Validate extension compatibility, data type changes and configuration differences.
  5. Implement blue‑green or rolling deployments: For high‑availability clusters, plan cutover strategies. With logical replication, run new and old clusters in parallel, replicate changes and switch clients during maintenance windows.
  6. Update platform and monitoring tooling: Ensure that backup scripts, infrastructure‑as‑code modules and monitoring dashboards support the target version. Replace deprecated parameters (e.g., wal_keep_segments replaced by wal_keep_size in version 13【724113118764390†L107-L112】) and adjust new defaults.
  7. Train stakeholders: Brief developers on new features such as the MERGE statement, JSON logging and replication options. Update runbooks to cover new administrative commands and performance tuning techniques.
  8. Validate after cutover: Compare performance metrics against pre‑upgrade baselines, verify that data integrity is preserved and monitor logs for new warnings. Run automated tests to ensure application functionality.

Governance and compliance alignment

Database upgrades are not purely technical; they intersect with risk management and compliance:

  • Risk registers: Add unsupported databases to risk registers and track remediation progress. Assign accountability to infrastructure teams and monitor upgrade milestones.
  • Change management: Follow formal change approval processes, documenting test results and back‑out plans. Provide stakeholders with upgrade schedules and communicate expected downtime.
  • Legal and regulatory considerations: Many data protection regulations require secure data storage. Document how moving to supported versions ensures encryption defaults, improved access controls and patching practices.
  • Stakeholder communication: Notify business owners and customers of upcoming database upgrades, emphasising benefits in reliability and security. For SaaS products, coordinate upgrades with clients and ensure service level agreements reflect the new environment.

Zeph Tech analysis

From a platform engineering perspective, PostgreSQL 13 delivered important internal improvements but now lags behind. The five‑year support window means organisations cannot defer upgrades indefinitely. PostgreSQL 15 and 16 add substantial new capabilities—SQL MERGE, logical replication on standbys, JSON logging, improved performance and new access control features—that justify the effort. Delaying upgrades increases cyber‑security risk, complicates compliance and hinders developer productivity. Zeph Tech recommends beginning migration planning early in 2025, performing inventory and compatibility assessments, piloting upgrades in non‑production environments and iterating on cutover strategies. Investing in this effort now will ensure databases remain secure, performant and aligned with evolving regulatory and business requirements.

Zeph Tech assists organisations in planning and executing PostgreSQL migrations, providing assessments, migration tooling and post‑upgrade validation to ensure seamless transitions to supported versions.

Timeline plotting source publication cadence sized by credibility.
4 publication timestamps supporting this briefing. Source data (JSON)
Horizontal bar chart of credibility scores per cited source.
Credibility scores for every source cited in this briefing. Source data (JSON)

Related briefings

Curated signals from the same pillar or overlapping topics.

Continue in the Developer pillar

Return to the hub for curated research and deep-dive guides.

Visit pillar hub

Latest guides

  • PostgreSQL
  • Database upgrades
  • End of life
  • Platform engineering
Back to curated briefings