PostgreSQL 14 End of Life: Stay, Upgrade or Replace?

PostgreSQL 14 reached end of life on November 12, 2026. If you still run it, you can stay on 14 for a while on paid extended support, upgrade to PostgreSQL 17 or 18, or replace Postgres for the workloads that never fit it. For most databases the answer is to upgrade. Staying only works as a short bridge with an end date, and replacing pays off where the data model or the need to scale out already hurts.

We build data migration tooling, so we usually see this decision from the replace side. We are not a Postgres upgrade shop, so for upgrade mechanics we link to the PostgreSQL and cloud provider docs.

When is PostgreSQL 14 end of life?

PostgreSQL 14 reached end of life on November 12, 2026 (PostgreSQL versioning policy). The project’s release announcement for 14.25 calls it the final release of PostgreSQL 14. That release fixed 52 security vulnerabilities and more than 140 bugs across the supported branches; fixes like these will no longer reach 14.

Community end-of-life dates for the versions still supported:

Version	End of life
15	Nov 11, 2027
16	Nov 9, 2028
17	Nov 8, 2029
18	Nov 14, 2030

Stay, upgrade or replace: how to decide

Upgrade to PostgreSQL 17 or 18 unless you have a specific reason not to; stay on 14 only as a paid bridge with an end date; replace Postgres only for workloads where you can name the problem a document model solves.

	Stay on 14	Upgrade to 17 or 18	Replace with a document database
Cost	Extended support fees from early 2027; self-managed gets no community fixes; third-party vendors sell backported patches	A test cycle, plus a maintenance window or a replication setup	Data model, query and code changes; often a lower running cost afterwards
Downtime	None now	A maintenance window with pg_upgrade, a short write freeze with logical replication	A short write freeze at cutover with an online migration
Main risk	Unpatched vulnerabilities pile up	Behavior changes between versions, missing extensions	The scope of the application changes
Best for	Buying a few months while you plan	Most databases	Workloads that fight the relational model or need to scale writes

Most teams will mix these: upgrade most databases, and move the one or two workloads that have been painful for years.

Should you stay on PostgreSQL 14?

Only as a bridge. Self-managed, you run a database that gets no more fixes. On a managed service you pay for extended support:

• Amazon RDS for PostgreSQL: standard support for 14 ends on February 28, 2027. Paid Extended Support runs from March 1, 2027 to February 28, 2030 (RDS for PostgreSQL release calendar). Aurora PostgreSQL 14 has the same dates (Aurora PostgreSQL release calendar).
• Azure Database for PostgreSQL flexible server: standard support ends on January 31, 2027, and Extended Support runs from February 1, 2027 to November 11, 2029 (Azure version policy, Azure Extended Support).
• Google Cloud SQL: 14 moves to paid extended support on February 1, 2027 and is deprecated on February 1, 2030 (Cloud SQL database versions).

Azure and Cloud SQL enroll servers in extended support automatically (Azure Extended Support, Cloud SQL extended support), and RDS does the same for instances created with Extended Support enabled (RDS Extended Support). If you do nothing, the charges start on the dates above.

AWS has not yet published a PostgreSQL 14 rate. Its pricing page gives a PostgreSQL 12 example of $0.100 per vCPU-hour in years 1 and 2 and $0.200 in year 3 (US East (Ohio)), charged on every vCPU, including Multi-AZ standbys and read replicas. At that rate an 8 vCPU instance costs about $584 a month. Pick the date you will be off 14 now and treat the fee as the cost of missing it.

Should you upgrade to PostgreSQL 17 or 18?

For most databases, yes. Both have had several minor releases and keep you supported until November 2029 and November 2030. Moving to 15 buys only one year.

There are two ways to do it, and managed services wrap both:

• In place with pg_upgrade. The database is down while it runs. With --link it hard-links data files, so the time depends mostly on the number of tables and indexes, and once the new cluster has started the old one can no longer be used: rollback is a restore from backup or a standby you held back. In copy mode the old cluster stays intact. On 18, initdb enables data checksums by default and pg_upgrade needs both clusters to match (PostgreSQL 18 release notes). Check SHOW data_checksums; on 14, then use initdb --no-data-checksums for the new cluster or enable checksums on the stopped 14 cluster with pg_checksums.
• Over logical replication to a new cluster. You stream changes from 14 to a new 17 or 18 cluster and switch the application over after a short write freeze. Every table needs a primary key or replica identity. DDL and sequence values do not replicate, so you set sequences at cutover.
• On a managed service, RDS offers a plain in-place major version upgrade with downtime (RDS major version upgrades), or a Blue/Green Deployment, which needs a 14.9 or later source and uses logical replication under the hood (Blue/Green replication types). Azure and Cloud SQL offer an in-place major version upgrade with the server offline while it runs (Azure, Cloud SQL).

Whichever you choose, do these before the real thing:

1. List every extension and confirm it exists for the target version.
2. Read the incompatibilities section of the release notes for every major version you skip.
3. Restore a recent production backup, run pg_upgrade --check and then the whole procedure against it, and time each step. The total is your real maintenance window.
4. Compare query plans for your slowest and most frequent queries on the new version.
5. Write down the rollback plan and test the restore.
6. Plan for statistics. After pg_upgrade to 17 the planner has no statistics until you run vacuumdb --all --analyze-in-stages; pg_upgrade to 18 carries most statistics over.

For choosing between a short outage and a live cutover, see Online vs. offline database migrations.

When should you replace PostgreSQL instead?

An end-of-life deadline forces a test cycle anyway, so it is a good moment to ask whether every workload belongs in Postgres. A document database such as MongoDB or Azure Cosmos DB tends to fit better when:

• Most queries join the same set of tables. If an order is always read with its line items and payments, storing them as one document removes the joins.
• One-to-many relationships are queried from the “many” side. Child rows that always belong to one parent can live in an indexed array inside the parent document.
• Your services work with domain entities that have their own lifecycle, such as a policy or a shipment that is created, changed and retired as a unit. Those map directly to objects, with little or no ORM mapping in between.
• Tables are mostly a key plus a large jsonb column, read and written as whole documents.

A data model designed around the workload’s real access patterns can need fewer indexes and fewer round trips, and so less hardware. In our experience that often cuts the cost of running the workload by 30 to 50 percent.

Scale is the other reason. Postgres has no built-in sharding. Scaling writes across machines means adding something on top: Citus, application-level sharding, or a newer option such as PlanetScale’s Neki, from the team behind Vitess. Each is a layer you have to choose, operate and design the schema around. Neki is new, and we would want to see a production track record before putting a tier-1 workload on it. Microsoft’s Azure HorizonDB, in public preview since June 2026, offers databases up to 128 TB and up to 15 read replicas, which scales storage and reads but, as far as the announcement says, not writes. MongoDB and Cosmos DB have sharding built in: you choose a shard key (a partition key in Cosmos DB) and the database spreads data and writes across nodes.

Moving costs you some things Postgres gives for free: ad hoc joins across entities, foreign keys and constraints enforced by the database, SQL reporting tools pointed at the same database, and a team that already knows Postgres. If the workload needs those, upgrade it.

Replacing is a bigger project than an upgrade, because the data model, queries and drivers all change. Do it for the workloads where you can name the problem it solves, and upgrade the rest in the same window:

1. Pick the workload and list its top queries and write paths.
2. Design the document model from those access patterns. Migrate RDBMS to MongoDB walks through it.
3. Change the data access layer and test it against a copy of the data.
4. Run the initial copy plus change data capture, and compare source and target.
5. Freeze writes briefly, cut over, and keep Postgres as the fallback for a set period.

How Dsync helps

Dsync copies data between databases with an initial sync followed by change data capture, so the cutover can happen with minimal downtime. It fits the replace path; for the 14 to 17 or 18 upgrade itself, use the tools above.

The native PostgreSQL connector reads the initial copy and ongoing changes through logical replication. Our supported systems page lists it for PostgreSQL 15 and later; if you are on 14, contact us and we will work through it with you. It needs wal_level=logical, permission to create a replication slot and a publication, a primary key on every table, and REPLICA IDENTITY FULL on tables with TOAST columns. The docs describe it for 1:1 migrations with transformations [CHECK: can the native PostgreSQL connector combine related tables into one document, or only map one table to one collection?].

The other route is the query-based SQLBatch connector, in public preview. It reads through SQL queries you write, including the change-tracking ones, so it has no minimum PostgreSQL version. Those queries are also how rows become documents: you write the query that joins the tables into the document you want, and the source database does the denormalizing.

If you are weighing the replace option for some of your PostgreSQL 14 workloads, our application re-platforming page describes how we approach it, or talk to an engineer about your schema.