PostgreSQL 9.6

PostgreSQL 9.6 added several substantial database-engine features over the preceding release line. It introduced parallel query execution for selected sequential scans, joins, and aggregates, allowing some analytic queries to use multiple CPU cores. It added declarative table partitioning was not introduced in this cycle; 9.6 instead improved the older inheritance- and trigger-based partitioning approach, so partitioned-table designs still required significant manual management. Other additions included native replication of synchronous standbys with multiple standby options, the ability to perform some vacuum work in parallel, improved full-text search, expanded monitoring views, and changes to reduce the impact of long-running transactions on replication and vacuuming. It also added the pg_basebackup --wal-method option and other replication and backup refinements. The release retained the pre-procedural partitioning, pre-logical-replication, and pre-SCRAM authentication architecture that later PostgreSQL versions replaced or extended.

This cycle has reached end of life, so upstream no longer provides fixes for newly discovered security vulnerabilities, data-corruption defects, planner errors, replication failures, or operational bugs. Continuing to run it therefore transfers defect assessment, mitigation, and incident risk to the operating team or a third-party support provider. It also leaves the platform without later improvements such as built-in declarative partitioning, logical replication, stronger SCRAM-SHA-256 password authentication, newer query-planning and parallel-execution capabilities, and many years of reliability, observability, backup, replication, and performance work. Compatibility risk rises over time as operating systems, client libraries, extensions, backup tools, drivers, and managed-service offerings stop testing against this server version. A direct jump from 9.6 to a current supported major version is feasible but is a larger change than a routine minor update: removed or changed parameters, extension compatibility, authentication settings, collation behavior, query plans, and application SQL assumptions all need validation.

Treat migration off 9.6 as a planned platform upgrade rather than an in-place patch. First inventory databases, roles, extensions, procedural languages, authentication methods, replication topology, backup and restore procedures, scheduled maintenance, and every application or tool that connects to the cluster. Select a currently supported target major version after confirming that required extensions, operating-system packages, drivers, and hosting options support it. Build a representative non-production target and rehearse the migration using either pg_upgrade for a short-cutover upgrade of compatible clusters, or logical dump and restore for a cleaner rebuild and greater flexibility. For low-downtime requirements, evaluate a staged migration based on logical replication or a supported migration tool, remembering that 9.6 does not provide the later built-in publication/subscription interface as a source. Run restore verification, integrity checks, application regression tests, performance tests with production-like data and concurrency, and failover and backup-recovery exercises. Review all configuration parameters rather than copying the old configuration file, rotate or modernize credentials where appropriate, update monitoring and maintenance automation, document a tested rollback plan, and schedule a cutover only after the rehearsal meets the agreed recovery-time and data-loss objectives.