PostgreSQL 17

PostgreSQL 17 added SQL-standard JSON_TABLE for turning JSON data into relational rows and columns, and added RETURNING support to MERGE. It introduced incremental physical backup support: pg_basebackup can create an incremental backup from a prior backup manifest, while pg_combinebackup can assemble the required backup files. Logical replication gained facilities to synchronize logical replication slots to standbys so replication can be resumed after a primary failover with less manual slot handling. The release also added OAuth-based authentication, a pg_dump filter-file option for selecting dump objects, and performance work in areas including vacuuming and query execution.

PostgreSQL 17 remains a supported major version, so staying on its current maintenance release remains a viable operating choice and continues to provide applicable bug and security fixes. The trade-off is that it will not gain capabilities and performance improvements delivered in later major versions. Teams that could benefit from newer planner, replication, backup, SQL, or administration changes may retain avoidable operational complexity or capacity costs. Deferring major-version testing also concentrates future migration work: extension compatibility, client-driver behavior, backup and restore validation, replica cutover procedures, and application query regressions will all need to be assessed later under greater time pressure.

Keep PostgreSQL 17 on its latest maintenance release while planning the next major-version move. Inventory extensions, procedural languages, client libraries, authentication integrations, backup tooling, monitoring agents, and replication topology, then confirm that each has a supported target-version path. Restore a representative PostgreSQL 17 backup into an isolated test environment and run application, performance, and operational tests against the intended newer version. Rehearse the chosen migration method: use pg_upgrade when a planned outage and compatible host layout are acceptable, or evaluate logical replication when a shorter application cutover is required. For logical replication, explicitly plan schema changes, sequence synchronization, large-object handling, replica identity requirements, and final write cutover, because logical replication does not automatically cover every database object or DDL change. Record rollback criteria, validate backup recovery before cutover, and measure the upgrade rehearsal rather than estimating the production window from database size alone.