PostgreSQL 14 reaches the end of community support on 12 November 2026. If it is still sitting underneath a production application, I would get the upgrade into the diary now. The database will not suddenly stop working, but leaving it there means accepting a version that no longer receives community fixes. That is a poor default for something holding the useful part of the business.
The date is on PostgreSQL’s versioning policy, alongside the support windows for newer branches. A major upgrade needs more thought than a patch update: check extensions, application compatibility and the migration method before picking a maintenance window. The pg_upgrade documentation is a useful starting point if you manage the server yourself; a hosted service will also have its own upgrade process.
For me, the rehearsal matters more than a reassuring estimate. Restore representative data into a separate environment, run the application against the target version, and check the queries people actually use. Measure how long the migration takes and decide how you would recover if it fails. A backup is useful evidence only when you know you can restore it.
There is no need to turn a database upgrade into a complete architecture project. Pick a supported target, prove the important behaviour, and give someone ownership of the change. November is close enough that “we will get round to it” is starting to look like a decision to leave it unsupported.