PostgreSQL 14: plan your upgrade
PostgreSQL 14 reaches the end of community support on 12 November 2026. If your application still depends on it, choose a supported target and rehearse the migration before the production cutover. Intercube can prepare the database and hosting environment, test the transfer with your team and take on ongoing infrastructure maintenance.
- Author
- Intercube
- Published
- Reading time
- 4 min read
01
Which deadline applies to your database?
The PostgreSQL versioning policy lists 12 November 2026 as the final release date for version 14. An existing database will keep running after the deadline. The operational change is that the community stops issuing fixes for that major version, including security and data integrity fixes.
Check who supplies updates for the database you actually run. AWS lists 28 February 2027 as the end of Amazon RDS standard support for PostgreSQL 14. That is a separate date from the upstream deadline. If you use RDS, check your instance settings and provider schedule before budgeting for an upgrade or Extended Support.
02
Choose the target around your application
Start by listing extensions, database drivers, scheduled jobs and services that connect to the database. Verify that your framework and every required extension support the target major version. Run tests with a restored copy of representative data, including the queries your application depends on most.
PostgreSQL documents a dump and restore or pg_upgrade for a major version change. The best route depends on the current host, data size, supported tooling and how long writes can pause. A provider-managed database may have its own upgrade tools. Choose the method after testing how long it takes and how much recovery work it leaves.
03
Rehearse the point where writes move
Restore a backup in the target environment and prove you can read and write through the application. Run critical jobs and compare permissions, record counts and representative results. Measure the test transfer and any time spent rebuilding indexes, so the production window reflects the work you actually need to do.
Agree when to pause writers and how to verify the last data changes made it to the new database. Define your rollback point before opening writes on the target. Switching the application back after new writes can lose or split data unless you have planned how to reconcile it.
- Keep a recoverable copy of the original database.
- Confirm connection secrets and worker settings on the new environment.
- Check application behaviour after switching traffic and monitor the first background jobs.
04
Move the database and hosting with one team
If your developers also maintain the database host, this deadline is a chance to move that work to Intercube. Our engineers can prepare managed PostgreSQL, review the dependencies with your application team and coordinate rehearsal and production cutover. We can align the database move with the application release and the checks that matter to your users.
Intercube operates the target infrastructure and agreed database service after the move. Your team stays responsible for application code and schema decisions, with engineers who understand how the database fits into your deployment and recovery plans. Migration to Intercube managed hosting is included at no additional cost.
Before PostgreSQL 14 support ends
- Check the upstream deadline and the schedule for your provider.
- Confirm extension and driver compatibility on the target version.
- Test a real restore and the transfer on representative data.
- Decide when writes pause and how to recover after cutover.
- Assign an owner for ongoing database maintenance.