PostgreSQL 14 End of Life (November 12, 2026; February 28, 2027 on RDS and Aurora): Every PostgreSQL EOL Date, Extended Support Costs, and a Tested Upgrade to 17 or 18

PostgreSQL 14 reaches end of life on November 12, 2026. After the final 14.x release on that day, the PostgreSQL project stops shipping bug and security fixes for it. On Amazon RDS and Aurora PostgreSQL, version 14 stays in standard support until February 28, 2027; from March 1, 2027 any instance still on 14 is moved into paid RDS Extended Support automatically (for PostgreSQL 13 that costs $0.10 per vCPU-hour, about $146 a month for a 2-vCPU instance), and when Extended Support ends on February 28, 2030, RDS upgrades it for you. Upgrade to PostgreSQL 17 or 18 now. Two traps we hit in testing: on RDS, minor versions 14.18 and 14.19 lose standard support on October 31, 2026, a week from now; and a self-managed pg_upgrade from 14 to 18 fails out of the box with "old cluster does not use data checksums but the new one does", because PostgreSQL 18 turns checksums on by default.

Ethan found the email on a Thursday: "Your Amazon RDS for PostgreSQL 14 instance will reach end of standard support." The inventory database had been running PostgreSQL 14 since the day Jake set it up, and nobody had touched its version since. "Is it going to stop working?" Ethan asked. "No," Jake said. "It's going to start costing money and stop getting fixes. Which is worse, slowly."

This guide covers what end of life actually means for PostgreSQL 14 on your own servers, in Docker and on Amazon RDS and Aurora; every PostgreSQL end-of-life date from 10 to 19 in one table; what Extended Support costs; and a tested upgrade from 14 to 18, including the errors you will meet and how we fixed each one. We ran PostgreSQL 14.24 and 18.6 side by side, with both versions' binaries installed in one container so pg_upgrade could run between them.

PostgreSQL 14 end of life: the dates that matter

There are four dates, and which one applies depends on where your database runs:

• October 31, 2026 (RDS minor versions): RDS for PostgreSQL 14.18 and 14.19 reach the end of standard support. If your instance is on one of them, move to 14.22 or 14.23 now, or better, go straight to a new major version. 14.20 follows in February 2027.
• November 12, 2026 (community end of life): the PostgreSQL project releases the final 14.x minor version and stops fixing 14. This is the date that matters for self-managed servers, Docker images and Linux packages.
• February 28, 2027 (RDS and Aurora end of standard support): RDS for PostgreSQL 14 and Aurora PostgreSQL 14 stay fully supported until this date, three and a half months past community end of life.
• March 1, 2027 to February 28, 2030 (RDS Extended Support): instances still on 14 are enrolled in paid Extended Support. Year 3 pricing, at double the rate, starts March 1, 2029. After February 28, 2030, RDS upgrades remaining instances automatically.

"Is Postgres 14 end of life?" Not quite yet, as of late October 2026. It will be in three weeks for the community, and in four months for RDS. Either way, the right time to plan is this week, not the week of the deadline.

Every PostgreSQL end-of-life date (10 to 19)

The PostgreSQL project supports each major version for five years, then releases a final minor version. RDS keeps each version in standard support a little longer, then offers up to three years of paid Extended Support. Here is the full calendar:

Aurora PostgreSQL 14 uses the same standard support end (February 28, 2027) and the same Extended Support window. If you are reading this for PostgreSQL 13: it is already in year 1 of Extended Support on RDS, which means you are already paying; the RDS vs Aurora cost guide shows how that shows up next to the instance price. For PostgreSQL 15 and 16, you have one and two more years respectively, so this is a good moment to plan those too.

What actually happens to a self-managed PostgreSQL 14 on November 12

Nothing visible. Your server keeps running, your queries keep working, and nobody switches anything off. What changes is underneath:

• No more security fixes. The next time a vulnerability is found that affects 14, the fix will ship for 15 through 19 only, and 14 will stay exposed.
• No more bug fixes, including data corruption fixes, which matter more than features.
• Packages and images freeze. The postgres:14 Docker image and the PGDG Linux packages stop getting new 14.x builds after the final release.
• Compliance starts asking. Many security standards and auditors treat running unsupported software as a finding in itself.
• Tools move on. Drivers, backup tools and extensions gradually stop testing against 14.

In other words, end of life is a slow risk, not a cliff. That is exactly why it gets ignored, and why Jake's "worse, slowly" is the right way to think about it.

RDS and Aurora PostgreSQL 14: how Extended Support works

On AWS, end of standard support does not upgrade your database by default. RDS enrolls it in RDS Extended Support, keeps applying critical security and bug fixes, and bills you for it. The rules:

• Enrollment is automatic from March 1, 2027 for every RDS for PostgreSQL 14 instance and Aurora PostgreSQL 14 cluster whose setting allows it, which is the default.
• You can opt out. The setting is called EngineLifecycleSupport. With open-source-rds-extended-support-disabled, the instance is upgraded to the next supported major version instead of being billed. If you change it on an instance that is already past standard support, the upgrade starts.
• It lasts up to three years. After February 28, 2030, RDS upgrades any remaining PostgreSQL 14 instances automatically.
• Aurora is set at the cluster level, RDS at the instance level.

Check the dates and your settings from the CLI:

# The support windows for a major version (standard and Extended Support, with start and end dates)
aws rds describe-db-major-engine-versions --engine postgres --major-engine-version 14

# Every PostgreSQL instance in this Region: version and Extended Support setting
aws rds describe-db-instances \
  --query "DBInstances[?Engine=='postgres'].[DBInstanceIdentifier,EngineVersion,EngineLifecycleSupport]" \
  --output table

# Opt one instance out (it will be upgraded instead of billed once standard support ends)
aws rds modify-db-instance --db-instance-identifier inventory-db \
  --engine-lifecycle-support open-source-rds-extended-support-disabled

The first command returns SupportedEngineLifecycles entries named open-source-rds-standard-support and open-source-rds-extended-support, each with a start and end date. Run the second command in every Region you use; old test databases in a forgotten Region are where Extended Support bills usually come from. Under the shared responsibility model, the version you run is your decision, and Extended Support is AWS charging for the extra work of patching versions the community no longer maintains.

What PostgreSQL 14 Extended Support will cost

Extended Support is billed per vCPU-hour for provisioned instances and per ACU-hour for Aurora Serverless v2, on top of the normal instance price. US East (N. Virginia) rates, October 2026:

The RDS price list does not carry a provisioned PostgreSQL 14 rate yet, but every earlier PostgreSQL version, 10 through 13, has used exactly $0.10 and $0.20. Worked examples at those rates:

db.t4g.micro or db.r6g.large (2 vCPUs):   2 x $0.10 x 730 h = $146.00 a month   (year 3: $292.00)
db.r6g.xlarge (4 vCPUs):                  4 x $0.10 x 730 h = $292.00 a month   (year 3: $584.00)
db.r6g.4xlarge (16 vCPUs):               16 x $0.10 x 730 h = $1,168.00 a month (year 3: $2,336.00)
Aurora Serverless v2 averaging 2 ACUs:    2 x $0.085 x 730 h = $124.10 a month   (year 3: $248.20)

For a micro instance that is free-tier sized, Extended Support costs several times the instance itself. Read that twice if you run a small database "because it's cheap". An upgrade is a few hours of work once; Extended Support is a bill every month for up to three years. Use those hours.

Which version should you upgrade PostgreSQL 14 to?

Choose 17 or 18. Both are mature, both are on RDS and Aurora, and both buy you years:

• PostgreSQL 18 (community support until November 14, 2030; RDS standard support until February 28, 2031): the newest stable release, with asynchronous I/O, faster upgrades that keep optimizer statistics, and the longest runway. Pick it unless an extension or tool you depend on does not support 18 yet.
• PostgreSQL 17 (until November 8, 2029; RDS until February 28, 2030): a year older, so slightly more battle-tested in third-party tools, and a safe choice if you are cautious or an extension lags.
• PostgreSQL 19 is at release candidate stage and not on RDS yet; do not wait for it to get off 14.
• 15 and 16 work, but you would be planning the next upgrade within one or two years. Skip them.

"Postgres 14 to 17" and "14 to 18" are single jumps. You do not need to stop at 15 and 16 on the way; pg_upgrade, dump and restore, and RDS major upgrades all go directly to the target, as long as RDS lists it as a valid target for your current minor version (the next section shows how to check).

What breaks between PostgreSQL 14 and 18 (tested)

Four major versions of changes land at once when you jump from 14. We ran the same script on 14.24 and on 18.6; these are the differences an application is most likely to hit:

Three of these need a word more:

The public schema. Since 15, new databases no longer let every user create objects in public. A database upgraded with pg_upgrade keeps its old permissions, but a fresh database, a restored dump into a new database, or a new environment built by your deploy scripts gets the new default, and apps that create tables as a non-owner fail. The "permission denied for schema public" guide has the three correct fixes.

Functions in indexes and the safe search_path. Since 17, CREATE INDEX, REINDEX, ANALYZE, VACUUM and materialized view refreshes run functions with search_path set to pg_catalog, pg_temp. A function used in an index that reads a table without a schema name stops finding it. Both fixes worked in our test: write public.codes inside the function, or add SET search_path = public to the function definition. Search your schema for functions used in index expressions before you upgrade, because an index that worked on 14 can fail the next time it is rebuilt.

Other removals to search for: vacuum_defer_cleanup_age (16), force_parallel_mode renamed debug_parallel_query (16), views created with manual ON SELECT rules (16), db_user_namespace and the adminpack extension (17), the plpython2u language (15), and the renamed pg_stat_statements timing columns (blk_read_time became shared_blk_read_time in 17). From 18, setting an MD5 password prints a deprecation warning.

pg_upgrade from 14 to 18: the checksum error and two fixes

For self-managed servers, pg_upgrade is the fast path: it moves the data files instead of reloading them. We created a PostgreSQL 14 cluster with the defaults, initialized a new 18 cluster with the defaults, and ran the check:

$ /usr/lib/postgresql/18/bin/pg_upgrade -b /usr/lib/postgresql/14/bin -B /usr/lib/postgresql/18/bin \
    -d /tmp/old14 -D /tmp/new18 --check
Performing Consistency Checks
-----------------------------
Checking cluster versions                                     ok

old cluster does not use data checksums but the new one does
Failure, exiting

PostgreSQL 14's initdb leaves data checksums off; 18's turns them on, and pg_upgrade requires both clusters to match. Two fixes, both tested:

1. Create the new cluster without checksums: initdb --no-data-checksums -D /tmp/new18. The check then reported *Clusters are compatible* and the upgrade completed. Quick, but you give up checksums.
2. Turn checksums on in the old cluster first, while it is stopped: pg_checksums --enable -D /tmp/old14. On our 139 MB test cluster that took about 9 seconds; it reads and rewrites every block, so plan proportionally longer for big databases. Then upgrade into a default 18 cluster and keep checksums, which detect silent disk corruption.

Then run the real upgrade. With --link, files are hard-linked rather than copied, which is fast but means you cannot start the old cluster again once the new one has run:

$ pg_upgrade ... --link
...
Upgrade Complete
----------------
Some statistics are not transferred by pg_upgrade.
Once you start the new server, consider running these two commands:
    /usr/lib/postgresql/18/bin/vacuumdb --all --analyze-in-stages --missing-stats-only
    /usr/lib/postgresql/18/bin/vacuumdb --all --analyze-only

Two things to do after it finishes. First, run those two vacuumdb commands: 18's pg_upgrade carries most optimizer statistics across (our upgraded table already had its column statistics), but not all of them. Second, update extensions: our pg_stat_statements was still at version 1.9 from 14, and pg_upgrade wrote an update_extensions.sql script to run as superuser. Delete the old cluster only after the new one has been in service for a while.

Upgrading RDS for PostgreSQL 14, step by step

On RDS you do not run pg_upgrade yourself; RDS runs it for you during a major version upgrade, including its pre-checks. Your job is preparation:

1. List valid targets for your current minor version:

   aws rds describe-db-engine-versions --engine postgres --engine-version 14.22 \
     --query "DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade==\`true\`].EngineVersion"

2. Create a parameter group for the new family (for example postgres18) and copy over any custom settings; a major upgrade needs a parameter group of the target family. Changes there may need a reboot, as the pending-reboot guide explains.
3. Check extensions. Update extensions such as PostGIS to versions the target supports before upgrading; the extension guide shows how to list what is installed and available.
4. Test on a copy: restore last night's snapshot to a new instance, upgrade that copy, and run your application's tests and slowest queries against it. If the upgrade pre-check fails, the details are in the pg_upgrade_precheck.log in the instance's logs.
5. Upgrade production with the least downtime your setup allows. A Blue/Green Deployment builds an upgraded copy that stays in sync, then switches traffic over with a short pause:

   aws rds create-blue-green-deployment --blue-green-deployment-name inventory-to-18 \
     --source arn:aws:rds:us-east-1:111122223333:db:inventory-db \
     --target-engine-version 18.1 --target-db-parameter-group-name inventory-pg18

   or, during a maintenance window, upgrade in place:

   aws rds modify-db-instance --db-instance-identifier inventory-db \
     --engine-version 18.1 --allow-major-version-upgrade \
     --db-parameter-group-name inventory-pg18 --apply-immediately

6. Run ANALYZE on the busiest tables right after, and watch CloudWatch for a day. An in-place upgrade shows the instance as "upgrading" for a while; if it seems stuck, the stuck-in-modifying guide tells you when to worry.

Replace 18.1 with the version your first step returned, and check how your read replicas will be handled before you start: they must end up on the same major version as the primary.

PostgreSQL 14 in Docker and on self-hosted apps

Self-hosters often run 14 without knowing it, because a docker-compose.yml pinned postgres:14 years ago. Check every compose file and Helm chart for postgres:14 or postgresql:14 tags.

To move a Docker database from 14 to 17 or 18, the dependable path is dump and restore: pg_dumpall from the 14 container, a fresh volume for the new one, and psql -v ON_ERROR_STOP=1 to load it. Two traps from our container tests: the official images for 18 and later keep data in /var/lib/postgresql/18/docker and expect the volume at /var/lib/postgresql, and pointing a new image at an old data volume makes the container refuse to start with "in 18+, these Docker images are configured to store database data in a format which is compatible with pg_ctlcluster". Use the newer version's pg_dump when you can; the version mismatch guide explains why the client version matters.

Some apps ship their own PostgreSQL 14. Immich, the self-hosted photo library, still pins a custom PostgreSQL 14 image with the VectorChord and pgvecto.rs vector extensions in its official compose file (release 3.3.5, October 21, 2026). Do not swap that image for a plain newer one yourself: the vector extensions have to match. Follow the app's own upgrade instructions when it moves, and keep its database off the public internet in the meantime.

Your PostgreSQL 14 upgrade checklist

1. Find every PostgreSQL 14: SELECT version(); on self-managed servers, the CLI query above in every AWS Region, and postgres:14 in compose files.
2. On RDS, move anything on 14.18 or 14.19 before October 31, 2026.
3. Pick the target: 18 unless something you depend on lags, then 17.
4. Search for the breakers: functions in index expressions, pg_start_backup in backup scripts, removed settings in config files and parameter groups, apps that create tables in public.
5. Test on a copy with the target version, including extensions and your slowest queries.
6. Upgrade: pg_upgrade (with matching checksum settings), dump and restore, or an RDS Blue/Green Deployment.
7. Run ANALYZE or the vacuumdb commands, update extensions, and watch for a day.
8. On RDS, decide the Extended Support setting for anything you cannot upgrade before February 28, 2027, and budget for it.

Ethan worked through the list in an afternoon. The inventory database was on 14.19, so the October 31 date was the real deadline, not February. He tested the upgrade on a restored copy on Friday and found one function in an index expression that read a lookup table without a schema name. "Would have failed the next time anything rebuilt that index," Jake said. "Probably at 3 a.m." Ethan added public. to the function and scheduled the Blue/Green switch for Sunday morning.

Errors you may hit after upgrading from PostgreSQL 14

old cluster does not use data checksums but the new one does

pg_upgrade from a 14 cluster into a default 18 cluster. Re-create the new cluster with initdb --no-data-checksums, or run pg_checksums --enable on the stopped old cluster first.

ERROR: permission denied for schema public

A new database on 15 or later, where users can no longer create objects in public by default. Grant CREATE on the schema to the app role, give the app its own schema, or make the app role the database owner.

ERROR: function pg_start_backup(unknown) does not exist

An old backup script. Since 15 the functions are pg_backup_start() and pg_backup_stop(), and exclusive backup mode is gone; better still, use pg_basebackup or your backup tool's current version.

ERROR: relation "..." does not exist (CONTEXT: SQL function "..." during inlining)

A function used in an index or by ANALYZE reads a table without a schema name, and 17 and later run maintenance with a safe search_path. Schema-qualify the table inside the function or add SET search_path to it.

ERROR: unrecognized configuration parameter "old_snapshot_threshold"

A setting removed in 17 (others: promote_trigger_file and vacuum_defer_cleanup_age in 16). Remove it from postgresql.conf or the parameter group.

ERROR: trailing junk after numeric literal

Since 15, text like 123abc is an error instead of a number followed by an alias. Add a space or AS: SELECT 123 AS abc.

WARNING: setting an MD5-encrypted password

MD5 passwords are deprecated from 18. Set password_encryption = 'scram-sha-256' and reset the password.

Frequently asked questions

Sunday's switchover was quick, and nobody at the shop noticed. On Monday Ethan opted every remaining test database out of Extended Support so none of them could quietly start billing in March, and put a reminder in the calendar for PostgreSQL 15: November 2027. Jake read it and moved it to November 2026. "Plan a year ahead," he said. "Not a week."

Revision note. Written October 23, 2026. "A stitch in time saves nine," the proverb says; an upgrade in October saves three years of Extended Support bills.