PostgreSQL 14 End of Life: What Managed PostgreSQL Teams Should Do Now

PostgreSQL 14 is approaching the end of its supported life. The PostgreSQL versioning policy lists PostgreSQL 14 as supported until its final release on November 12, 2026, while PostgreSQL 13 is already unsupported and PostgreSQL 15 through 18 remain in active support. For teams still running production workloads on 14, this is the point where an upgrade should move from backlog item to scheduled operational work.

The practical risk is not that PostgreSQL 14 suddenly stops working the day after support ends. The risk is that future bug fixes and security fixes will no longer arrive for that major version. If a provider, internal platform, or compliance process requires supported database software, waiting until the deadline compresses testing, extension checks, rollback planning, and application compatibility work into the worst possible window.

What changed in the support calendar

PostgreSQL uses a predictable support model. The PostgreSQL Global Development Group releases a new major version about once per year and publishes minor releases for supported major versions at least once every three months. Major versions receive bug fixes and security fixes during their support window, and unsupported versions drop out of that routine maintenance stream.

As of the current PostgreSQL versioning page, the supported major versions are 14, 15, 16, 17, and 18. PostgreSQL 14 is the oldest supported line and is scheduled for final release on November 12, 2026. PostgreSQL 18 is the current stable major version, and PostgreSQL 19 is in development preview through beta releases. That gives PostgreSQL 14 users a clear migration target window: upgrade while the old version is still supported, not after it has become an emergency.

The key decision is not only which version to land on. It is how much time the team leaves for discovery. Extensions, collation behavior, SQL syntax, query plans, driver settings, and operational tooling can all affect upgrade readiness even when the database schema itself looks ordinary.

Why this matters for managed PostgreSQL users

Managed PostgreSQL removes a large amount of server administration, but it does not remove application compatibility. A provider can expose an upgrade workflow, take backups, automate parts of the process, and manage the underlying machines. The application team still owns the schema, extensions, query behavior, migration schedule, connection strings, and validation criteria.

This is especially important for SaaS applications that have background workers, analytics jobs, cron tasks, BI clients, and customer-facing traffic sharing the same database. A major-version upgrade should prove that ordinary requests work, but also that jobs, migrations, backups, restore workflows, connection poolers, and monitoring still behave as expected. If PgBouncer is in the path, test the application through the same pooling mode used in production rather than only against a direct database connection.

There is also a security and audit angle. After a PostgreSQL major version becomes unsupported, the team can no longer rely on upstream minor releases for that version. If an audit asks whether production databases run supported software, an end-of-life major version is hard to defend. Even when the immediate technical risk feels low, the governance risk increases.

A safe upgrade plan before the deadline

Start with an inventory. List every PostgreSQL 14 database, its owner, application, extensions, connection path, backup policy, maintenance window, and restore expectations. Include staging, preview, and internal systems because forgotten databases often become the systems that block platform changes later.

Next, choose a target version. For many teams, PostgreSQL 17 or 18 will be the sensible target depending on provider availability, extension support, and internal risk tolerance. Jumping to the newest stable version gives a longer support runway, but some organizations prefer one-version-back once it has been exercised broadly in their environment. The important point is to avoid upgrading from 14 to 15 by habit if that only buys a short extension before another upgrade conversation.

Build a rehearsal environment from a recent production backup or managed restore. Run application smoke tests, important background jobs, representative read and write paths, migrations, and operational checks. Review extension versions and any provider-specific limitations before the maintenance window. If the dataset is large, measure restore time and upgrade duration rather than assuming they will fit inside a convenient deploy window.

The PostgreSQL documentation describes several upgrade approaches: dump and restore, pg_upgrade, and replication-based upgrades. Managed providers may abstract those choices, but the tradeoffs still matter. Dump and restore is simple to reason about but can be slow for large databases. pg_upgrade is designed to upgrade data files to a later major version without the full dump and restore path, but it depends on provider support and careful preparation. Replication-based migrations can reduce downtime, but they introduce more moving parts and validation work.

What to validate after the upgrade

The first validation step is boring on purpose: confirm the application can connect, read, write, run migrations, and complete the most important user flows. Then check the database from the operations side. Watch slow queries, error rates, connection counts, lock waits, replication or backup status, and job queues. Query plans can change across major versions because planner improvements and statistics behavior evolve, so the post-upgrade review should include the endpoints and reports that are most expensive today.

Do not treat a successful startup as a complete validation. Run the billing job, the nightly export, the tenant provisioning path, the largest customer dashboard, and the restore procedure if recovery requirements are strict. If the application uses session-level settings, prepared statements, temporary tables, or LISTEN/NOTIFY, make sure those paths behave through the same connection pooling setup used by production.

For teams using ArmorDB or another managed PostgreSQL provider, this is also a good time to review whether the current plan still matches the workload. An upgrade window often exposes old assumptions about storage growth, connection counts, backups, and maintenance headroom. The ArmorDB guide to managed PostgreSQL instance sizing can help frame that review without turning the version upgrade into a blind plan upgrade.

Common mistakes to avoid

The most common mistake is waiting for a provider warning email and treating it as the beginning of the project. By then, the platform team may already be scheduling many customers through the same narrow window, and internal testing time may be scarce.

Another mistake is testing only schema migration success. A database can upgrade cleanly while a reporting query becomes slower, an extension version changes behavior, or a pooler-facing code path exposes a driver assumption. The rehearsal should include production-like traffic paths, not only DDL.

A third mistake is skipping rollback and restore planning because the database is managed. Managed backups are valuable, but the team still needs to know the restore point, expected restore time, application cutover steps, and what data loss or write freeze is acceptable if rollback is needed.

Sources / further reading

• PostgreSQL: Versioning Policy
• PostgreSQL documentation: Upgrading a PostgreSQL Cluster
• PostgreSQL documentation: pg_upgrade
• PostgreSQL documentation: Backup and Restore

Practical takeaway

PostgreSQL 14 still has time left, but the support clock is now short enough to act. Inventory production databases, pick a supported target version, rehearse with real data, validate application and operational paths, and schedule the upgrade before November 2026 becomes a deadline-driven incident. The best upgrade is the one that finishes while the old version is still supported and the team still has room to fix surprises calmly.