PostgreSQL 14 Will Reach End of Support in November 2026: Upgrade to 17 or 18?

Default choice: evaluate PostgreSQL 17 first. Choose PostgreSQL 18 only after your application, drivers, and extensions pass migration testing and you have a concrete need for its new features. PostgreSQL 14 support ends on November 12, 2026, so start the assessment now; use rehearsal results, not the calendar alone, to approve the target version. (Official version lifecycle)

This is for DBAs still running PostgreSQL 14 and responsible for lifecycle planning or change approval.
Backend and data engineers can use the same checks to build a migration plan that includes recovery and rollback.

Last updated October 21, 2026. Version and support dates checked against the PostgreSQL version lifecycle page and the PostgreSQL 18.6 release notes.

PostgreSQL 14 upgrade: choose PostgreSQL 17 or 18

PostgreSQL 14 reaching end of support does not mean an existing database stops running on that date. It does mean that staying on the version becomes a less defensible operational choice: the PostgreSQL lifecycle page lists its final support date as November 12, 2026. Treat that date as a deadline for having a supported-version plan, not as a reason to skip application checks or rush an untested cutover.

The choice is not simply “older is safer” versus “newer is faster.” PostgreSQL 17 gives teams a more conservative target when extension and application compatibility are the primary concerns. PostgreSQL 18 is a reasonable target when the entire stack has been verified and the team can identify a feature that matters to its workload. The PostgreSQL 18 release notes document changes that teams must review before upgrading; they do not establish that every application will benefit from the new release. (PostgreSQL 18 release notes)

Use these decision branches to choose a target:

• Choose PostgreSQL 17 for the initial migration assessment if you prioritize reducing change scope, have extensions or drivers that need additional validation, or cannot yet show a specific PostgreSQL 18 feature requirement.
• Choose PostgreSQL 18 if your application, client drivers, operating-system packages, and every required extension are confirmed compatible, and a tested workload demonstrates a reason to adopt its features.
• Hold the change and fix the migration plan if a required extension has no supported target-version build, your restore process has not been rehearsed, or you have no approved rollback trigger.
• Do not stay on PostgreSQL 14 by default simply because the database continues to start after support ends. If the cutover cannot be completed in time, document the exposure, restrict unnecessary changes, and set an approved migration date rather than treating continued operation as a completed plan.

Can a team keep running PostgreSQL 14 after support ends? The software does not automatically stop running on November 12, 2026. But the lifecycle page marks that date as the end of support, so continued use should be a temporary, explicitly accepted exception with a migration owner and a recovery plan—not an indefinite substitute for upgrading.

Support dates set the migration deadline, not the target version

The lifecycle comparison matters because choosing a target also determines how soon the team must plan its next major-version upgrade. The official page, checked for this article on October 21, 2026, lists PostgreSQL 14.24, 17.11, and 18.6 as current minor releases for those branches, with support ending on the dates below. Always recheck the official page before scheduling a production change; minor releases can advance, and a minor update is not the same operation as a major-version upgrade. (PostgreSQL version lifecycle)

The release numbers and support dates in the table come from the linked official lifecycle page and the PostgreSQL 18.6 release notes cited above. The later end date for PostgreSQL 18 is useful for planning, but it does not by itself make PostgreSQL 18 the right destination. A longer support window cannot compensate for an unsupported extension, an incompatible driver, or an untested restore procedure.

Build the target-version choice around your team’s next lifecycle review. If the team expects to update PostgreSQL regularly and can validate the application stack, PostgreSQL 18 may fit that plan. If the current migration is already constrained by extension availability or tightly controlled change windows, PostgreSQL 17 may be the better near-term target. In either case, keep minor releases current within the chosen branch according to your change process; do not confuse that routine maintenance with the major migration decision.

Compatibility is the first release gate

A database server can accept connections after an upgrade while application behavior is still wrong. Compatibility review must cover the full production path, not just whether the target server starts. Record the installed version and support status of each dependency, then confirm that the maintainers support the target major release and that the exact package or build is available in the deployment environment.

Check these items before approving either target:

• Application SQL and behavior: Run integration tests against a copy of production data. Look for changed assumptions about query results, transaction behavior, types, extensions, and error handling.
• Client drivers and connection pools: Verify the driver versions used by each application and job. Check pool startup, reconnect behavior, TLS configuration, and how the service handles a database restart.
• Extensions: List every installed extension, its version, and whether the extension publisher supplies a compatible build for the target. Test extension installation and upgrade behavior in a clone. Do not infer general compatibility from one successful installation in a different environment.
• Operating-system packages and deployment automation: Confirm that the target server packages exist for the operating system in use. Review container images, configuration management, monitoring agents, backup tooling, and scheduled maintenance jobs.
• Operational integrations: Validate alerting, metrics collection, log parsing, replication, backup retention, and the procedures used by on-call staff.

PostgreSQL 18 needs a specific review of its release notes and upgrade documentation. Identify changes that intersect with your extensions, SQL, administration scripts, and deployment process; classify each as “tested,” “not used,” or “blocking.” The official PostgreSQL 18 release notes are the source for release-specific changes. They are not a universal extension compatibility matrix, so the team must confirm compatibility with the maintainers and test the exact versions it runs.

Which extensions should be checked before moving PostgreSQL 14 to 18? Check every extension installed in the source database, including extensions used by only one application or maintenance job. Record its current version, target-version availability, installation source, upgrade procedure, and test result. If a required extension is unavailable or its behavior is unverified, treat PostgreSQL 18 as blocked until the issue is resolved; do not assume that an extension working on one operating system will work on all builds.

A useful compatibility record is specific enough for another engineer to reproduce. For each component, note the source version, proposed target, package or build source, test environment, observed result, and the person who approved the result. This catches a common failure in migration reviews: the application team verifies its driver, while the deployment team later discovers that the production image or extension repository does not provide the required target build.

Step-by-step migration rehearsal and rollback

Do not treat a major upgrade as replacing the database executable and restarting the service. PostgreSQL’s upgrade documentation describes distinct approaches, each with operational requirements. The correct path depends on the maintenance window, dataset, replication design, available temporary space, and the team’s acceptable recovery point. (PostgreSQL upgrading documentation)

Use a rehearsal as a release gate:

• Inventory the source. Record the PostgreSQL 14 minor release, database sizes, extensions, roles, tablespaces, replication setup, scheduled jobs, backup method, and application connection details. Compare the inventory with the compatibility checklist.
• Select the target and migration method. Evaluate pg_upgrade, logical dump and restore, or logical replication against the actual system constraints. Read the relevant official procedure before choosing: the pg_upgrade documentation and logical replication upgrade guidance explain different mechanisms and limitations.
• Prepare an isolated rehearsal environment. Use a recent, representative backup or a controlled copy of production data. Keep it isolated from production writes and verify that the target packages, extensions, configuration, and automation are the same versions planned for the cutover.
• Measure the whole procedure. Record time spent on preparation, migration, validation, application reconnection, and any required follow-up work. A successful database conversion alone is not the end of the change window.
• Run application and data checks. Exercise critical reads and writes, scheduled jobs, reporting, connection pooling, and any workflows that depend on extensions. Compare key outputs with the source and investigate differences before approving production.
• Test recovery, not only migration. Restore the backup into a separate environment and confirm that the restored service can be started, queried, and used by the application. PostgreSQL’s backup and restore documentation covers the supported approaches; your own rehearsal must verify your specific scripts and retention process.
• Approve cutover and rollback conditions. Name the person who authorizes the change. Define the conditions that stop the cutover, the point after which writes must not return to the old system, and the recovery route if validation fails.

The rehearsal should preserve evidence: logs, command output, timings, validation results, and unresolved issues. This record helps the change approver distinguish a repeatable migration from a one-time success dependent on undocumented manual steps.

Operational note: A rollback plan must account for writes accepted after cutover. Simply starting the old server does not make it consistent with a newer server that has already accepted production changes. Decide before the change how those writes will be reconciled or how service will be restored from a known recovery point.

Downtime depends on migration path and workload

How long will a PostgreSQL 14 pg_upgrade take? There is no defensible fixed duration without testing the source database, storage, configuration, extensions, and selected procedure. pg_upgrade has its own documented requirements, but a production estimate must include pre-checks, service shutdown, upgrade work, validation, and application reconnect—not only the command’s runtime.

Choose the method against your downtime and recovery requirements:

• pg_upgrade is a candidate when its documented requirements fit the environment and a rehearsal shows that its downtime is acceptable. Validate the exact procedure and extension handling against the official documentation linked above.
• Logical dump and restore can provide a straightforward, auditable path, but the team must test the time required to export, transfer if needed, restore, rebuild dependent objects, and validate the result. Do not approve it based on a small test database if production has a different data profile.
• Logical replication may support a more controlled transition where the source and target can run in parallel, but it adds setup, synchronization, and cutover work. Confirm the restrictions and sequence in the official logical replication upgrade guide linked above rather than assuming it is a drop-in zero-downtime method.

For each candidate, make a run sheet that identifies the action, owner, expected evidence, stop condition, and recovery step. Include the period when writes are paused or redirected, the checks required before reopening traffic, and the process for handling a failed application validation. Measure these steps in the rehearsal rather than inventing a downtime estimate from a general rule.

The same discipline applies to performance claims. PostgreSQL 18 may include changes relevant to a particular workload, but release notes are not a benchmark for your queries, data distribution, hardware, or extensions. Compare representative query plans and application-level behavior in the rehearsal. If the feature benefit is not measurable or operationally relevant, it is not a sound reason to add migration risk.

Prepare storage, backups, and the operating environment

Estimate the resources required from your own data and procedure. Account for the database files, temporary migration space, WAL growth, backup retention, logs, and any parallel source-and-target operation. A design that has room for the live database but not for the chosen migration path can fail before compatibility testing is complete. Do not assume that a larger server or faster storage automatically makes an untested upgrade safe.

Plan for data protection independently of the server choice. PostgreSQL’s backup documentation describes backup and recovery approaches, but the production owner still needs to choose retention, storage location, access controls, and a restore test schedule that match the service’s recovery objectives. Keep a recovery copy outside the database host; a second disk in the same machine is not an off-host backup.

If a deployment uses a server without hardware RAID, explicitly choose software mirroring or database replication for the required redundancy, and document how the team will detect and recover from a disk failure. Replication is not a substitute for backup: unwanted changes or application-level deletion can be copied to a replica. Test both the database migration and the independent restore process before moving production traffic.

For an upgrade that also includes a move to dedicated infrastructure, compare the current environment with the actual options shown on CloudUDP’s plans page. Confirm available memory, direct NVMe options, operating systems, and billing terms there before estimating capacity or cost; do not assume an unverified configuration. For connection and operating-system access procedures, review the CloudUDP access guide alongside the database runbook.

A managed database can reduce the amount of infrastructure work your team owns, so it may remain the better fit when operational simplicity outweighs infrastructure control. But if the current arrangement is constrained by a managed service’s available configuration, recurring storage or I/O pricing, or limited control over the operating environment, an exclusive AMD bare-metal server may be more suitable for a database your team is prepared to operate. The trade-off is direct: you gain control over the server and storage layout, but you also own backups, replication or software RAID, monitoring, patching, and recovery drills.

Before moving, finish the PostgreSQL compatibility inventory and restore rehearsal; then compare the target database requirements with CloudUDP’s currently listed memory, direct NVMe, and operating-system options. If the tested migration plan fits an exclusive server and your team can own its operational responsibilities, review the available CloudUDP plans before committing to the new host.