Free audit

View Audit Scope
PostgreSQL Major UpgradesPostgreSQL 12, 13 & 14 EOL Exit to 16 & 17

PostgreSQL Major Version Upgrades to 16 & 17

JusDB engineers low-downtime major version upgrades from PostgreSQL 12 (EOL November 2024), PostgreSQL 13 (EOL November 2025), and PostgreSQL 14 (EOL November 2026) to PostgreSQL 16 and 17. Senior PostgreSQL consultants execute pg_upgrade --check pre-flight audits, validate PostGIS, TimescaleDB, and pgvector extensions, check OS glibc collation versions, and run rehearsed cutovers via pg_upgrade --link hard-links, AWS RDS Blue/Green Deployments, or logical replication.

PostgreSQL 13 is past community and RDS standard support, and PostgreSQL 14 reaches community EOL on 12 November 2026. We turn high-risk major upgrades into rehearsed, deterministic engineering events.

The first 30-minute call covers your databases, current ownership, and required coverage. No production access is needed. Mutual NDA before access · pre-flight pg_upgrade --check · explicit rollback gate.

PostgreSQL Upgrade Paths

Select an upgrade path

PG 12 & 13 EOL Exit

Past EOL

PostgreSQL 12 reached community EOL in November 2024 and PostgreSQL 13 reached EOL on 13 November 2025 (RDS standard support ended 28 February 2026).

Remaining RDS/Aurora PG 12 and 13 clusters incur per-vCPU-hour Extended Support surcharges until upgraded to PG 16 or 17.

Estimate RDS Extended Support exposure

Covers self-managed Linux, Patroni, CloudNativePG, Amazon RDS, Aurora PostgreSQL, Cloud SQL, and Azure.

P1 initial-response target
15 minutes for critical (P1) incidents under a 24x7 support agreement; 2 to 4 hours in business hours
Source & target versions
Upgrade from PG 10, 11, 12, 13, 14, or 15 directly to PostgreSQL 16, 17, or 18
Cutover architectures
pg_upgrade --link hard-links · native logical replication · pglogical · RDS Blue/Green
Pre-flight verification
Extension dependency matrix · OS glibc collation audit · PUBLIC schema & SCRAM checks

Selected clients

  • Innoviti
  • Blitz
  • Freecharge
  • Nango
  • Recochain
  • Screen Facts
  • Nexora
  • WeCredit

Why major version upgrades fail without pre-flight engineering

PostgreSQL 15, 16 & 17 breaking changes we catch before cutover

A major PostgreSQL upgrade is not just a binary swap. Permission model changes, OS glibc collation drift, extension ordering, and empty planner statistics can break production if left unchecked.

PostgreSQL major version breaking changes, what happens at cutover, and how JusDB prevents them
Breaking Change / RiskWhat happens if unaddressedOur pre-flight & cutover remediation
PUBLIC Schema CREATE RevokedMigrations and apps fail with 'permission denied for schema public'PostgreSQL 15+ revokes default CREATE permission on the public schema from PUBLIC (CVE-2018-1058 mitigation) and assigns ownership to pg_database_owner.Audit application and Flyway/Liquibase migration roles before cutover and issue explicit GRANT CREATE ON SCHEMA public TO <app_role> where required.
glibc Collation Index DriftSilent wrong-row lookups or duplicate PK errors after OS + PG upgradeMoving a physical data directory (via pg_upgrade or streaming replica) across Linux OS versions with a newer glibc changes text sort order beneath existing B-tree indexes.Compare pg_collation.collversion against pg_collation_actual_version(oid); use logical replication or run REINDEX DATABASE CONCURRENTLY after OS changes.
Extension Version Matrix Trappg_upgrade aborts on PostGIS, TimescaleDB, pgvector, or pgauditC-language shared libraries must exist in the target binary tree and often require stepping through a bridge extension version before upgrading PostgreSQL.Inventory pg_available_extensions and shared_preload_libraries, upgrade extensions on a staging clone first, and run pg_upgrade --check.
Missing pg_statistic HistogramsCPU hits maximum capacity and queries run Seq Scans right after cutoverpg_upgrade transfers table and index files but does not copy optimizer statistics in pg_statistic, leaving the new planner blind until ANALYZE completes.Execute vacuumdb --all --analyze-in-stages --jobs=N immediately inside the cutover gate before opening full application traffic.
scram-sha-256 Auth RejectionLegacy drivers and poolers fail authentication on PostgreSQL 15/16/17Modern PostgreSQL defaults password_encryption to scram-sha-256 and restricts legacy md5 hashes in pg_hba.conf or PgBouncer userlists.Audit pg_authid password hashes (rolpassword NOT LIKE 'SCRAM-SHA-256%'), test JDBC/libpq/PgBouncer drivers, and rotate hashes prior to cutover.
Removed Catalog & GUC SettingsMonitoring exporters break or postmaster refuses to start on PG 17PostgreSQL 15-17 removed promote_trigger_file, stats_temp_directory, old_snapshot_threshold, and moved checkpoint metrics out of pg_stat_bgwriter into pg_stat_checkpointer.Diff postgresql.conf against target pg_settings, update Prometheus postgres_exporter queries for pg_stat_checkpointer and pg_stat_io, and validate startup.

Upgrade engineering scope

Six workstreams for a predictable PostgreSQL major upgrade

We handle every step from extension compatibility and glibc collation checks to cutover execution and post-upgrade query plan verification.

  • Pre-Flight Compatibility & Extension Audit

    We inspect every catalog dependency, extension version, custom function, and deprecated parameter before scheduling your maintenance window.

    • Full pg_upgrade --check validation against a production snapshot clone
    • PostGIS, TimescaleDB, pgvector, Citus, and Foreign Data Wrapper checks

    pg_upgrade --check · pg_available_extensions · pg_settings diff

  • Collation, glibc & Authentication Hardening

    Eliminate silent B-tree index corruption from OS locale updates and prevent post-cutover authentication lockouts.

    • OS glibc and ICU collation version verification across pg_collation
    • PUBLIC schema privilege audit and md5 to scram-sha-256 credential migration

    pg_collation_actual_version · pg_authid · amcheck (bt_index_check)

  • pg_upgrade --link Hard-Link Execution

    When an in-place maintenance window is preferred, we use filesystem hard links to upgrade multi-terabyte clusters without copying data blocks.

    • Parallel catalog dump/restore with pg_upgrade --link --jobs=N
    • Standby rsync alignment so streaming replicas do not require full reseeding

    pg_upgrade --link · rsync --size-only · vacuumdb --analyze-in-stages

  • Logical Replication & RDS Blue/Green Cutovers

    For strict uptime requirements, we build a side-by-side PG 16 or 17 cluster and stream live writes until the cutover second.

    • Native logical replication, pglogical, or AWS RDS Blue/Green orchestration
    • Automated sequence synchronization and chunked row-hash verification

    CREATE PUBLICATION / SUBSCRIPTION · AWS RDS Blue/Green · pglogical

    PostgreSQL migration services
  • Query Plan Regression Testing on PG 16 & 17

    Major version planner enhancements can occasionally flip execution plans on edge-case queries. We catch and fix them on staging first.

    • Compare top pg_stat_statements plans between PG 13/14 and PG 16/17
    • Tune new PG 16/17 features (memoize, incremental sort, parallel Hash Join)

    EXPLAIN (ANALYZE, BUFFERS) · pg_stat_statements · auto_explain

    PostgreSQL performance tuning
  • Observability Migration & Hypercare

    Update your monitoring stack for PostgreSQL 16 and 17 catalog changes and guard the cluster through post-cutover traffic peaks.

    • Update dashboards for pg_stat_io (PG 16+) and pg_stat_checkpointer (PG 17+)
    • Reverse-replication rollback gate and 15-minute P1 support where contracted

    pg_stat_io · pg_stat_checkpointer · postgres_exporter · PgBouncer

    Enterprise PostgreSQL support

Shared responsibility, SLAs & upgrade methods

Why cloud one-click upgrades still require database engineering

Managed cloud databases automate much of the infrastructure layer, but your team still owns query performance, capacity, cost, and incident decisions. Initial-response targets are 2 to 4 hours during covered business hours, Mon–Fri 09:00–18:00 IST (UTC+5:30). Where your service agreement includes 24x7 on-call, the initial-response target for P1 incidents is 15 minutes. Targets are not resolution guarantees. Standard business hours run 03:30–12:30 UTC.

PostgreSQL major upgrade responsibilities across managed cloud and self-managed environments
Upgrade ResponsibilityManaged Cloud (RDS, Aurora, Cloud SQL, Azure)Self-Managed Linux or Kubernetes
Pre-flight extension, PUBLIC schema & auth auditsClicking 'Modify -> Engine Version' in RDS/Cloud SQL does not fix PG 15+ PUBLIC schema permissions or driver SCRAM errors. JusDB audits and fixes them pre-cutover.JusDB runs pg_upgrade --check, upgrades PostGIS/TimescaleDB/pgvector in the required order, and migrates md5 roles to scram-sha-256.
OS glibc collation drift & B-tree index integrityCloud image upgrades can still introduce collation version notices. JusDB verifies pg_collation versions and runs amcheck / REINDEX CONCURRENTLY.JusDB audits OS glibc locale changes across Debian/Ubuntu/RHEL upgrades and eliminates silent B-tree corruption via logical cutovers or concurrent reindexing.
Low-downtime cutover & sequence synchronizationRDS Blue/Green blocks on incompatible DDL or long transactions. JusDB tunes the Blue/Green or logical replication pipeline and scripts sequence sync.JusDB executes pg_upgrade --link hard-link cutovers with rsync standby alignment or native logical replication cutovers.
Post-upgrade statistics & query plan stabilizationIn-place cloud upgrades wipe optimizer statistics, causing immediate CPU spikes. JusDB runs parallel staged ANALYZE and guards top query plans.JusDB executes vacuumdb --all --analyze-in-stages --jobs=N immediately after pg_upgrade and updates Prometheus/Grafana for pg_stat_checkpointer.

Your team keeps control

  • Set business priorities, application requirements, and release plans
  • Approve production changes, except routine actions you have pre-approved
  • Own your cloud accounts, access policies, and vendor relationships
  • Decide when maintenance can happen and how quickly service must recover
  • Move the work in-house or to another provider after your agreement's notice period, with your data returned or deleted and the transition help your agreement sets out (Terms, section 8)

JusDB handles the agreed PostgreSQL upgrade work

  • Monitor database health, investigate alerts, and involve the right people
  • Review query performance, replication, capacity, and backup health
  • Carry out approved changes and update the operating instructions they affect
  • Report completed work, open risks, and recommended next steps

Published initial-response targets during cutover & hypercare

  • 2 to 4 hours

    Business hours

    During covered business hours

  • 15 minutes

    24x7 on-call

    P1 incidents

SeverityInitial responseDefinitionChannel & coverage
P1 · Critical15 minutesProduction database down, primary unreachable, data corruption risk, or active failover event.24x7 on-call (under your service agreement) · Direct PagerDuty, Opsgenie, or phone page plus incident bridge
P2 · High30 minutesSevere latency spike, replication lag climbing rapidly, connection exhaustion, or degraded HA node.24x7 on-call (under your service agreement) · On-call alert plus shared Slack or Teams channel
P3 · Medium60 minutesNon-critical slow query regression, staging issue, backup warning, or replication check alert.24x7 on-call (under your service agreement) · Shared Slack or Teams channel or support ticket
P4 · Low90 minutesConfiguration question, index advisory, planned schema review, or general operational request.24x7 on-call (under your service agreement) · Shared Slack or Teams channel or support ticket

Our engineering team is in India; business-hours coverage is Mon–Fri 09:00–18:00 IST (UTC+5:30), and 24x7 on-call is available under your service agreement.

Initial-response targets, not resolution guarantees. The target for your engagement is set in your service agreement.

Comparison of PostgreSQL major version upgrade methods
Upgrade MethodTypical Write PauseBest Suited ForEngineering Tradeoffs
Logical Replication / RDS Blue-GreenSeconds to < 2 minutes (write pause)24x7 transactional workloads under a 24x7 support agreement, multi-TB databases, and upgrades crossing OS glibc versions.Requires temporary 2x storage footprint, primary keys / REPLICA IDENTITY on all tables, and scripted sequence synchronization at cutover.
pg_upgrade --link (Hard-Link Mode)5 to 25 minutes (depends on schema object count)Multi-terabyte self-managed clusters where source and target share the same filesystem and OS glibc version.Modifies the source data directory linkage (requires a verified backup or snapshot fallback) and requires immediate vacuumdb --analyze-in-stages.
In-Place Cloud Modify / pg_upgrade Copy20 to 90+ minutes (plus replica rebuilds)Development, staging, or internal systems with generous maintenance windows and simple extension footprints.Longest write outage; no instant switchback if an application driver or query plan regresses after cutover.
Interactive AWS RDS / Aurora PostgreSQL Extended Support Exposure Estimator

Calculate Your Annual PostgreSQL 11-14 Extended Support vCPU-Hour Exposure

Amazon RDS and Aurora PostgreSQL bill Extended Support per provisioned vCPU-hour across every primary, Multi-AZ standby, and read replica instance running PostgreSQL 11, 12, 13, or 14 after standard support ends. Upgrading to PostgreSQL 16 or 17 eliminates this surcharge entirely.

PostgreSQL 13 reached community EOL in November 2025; AWS RDS Extended Support Year 1-2 began March 1, 2026.

32 vCPUs
2 (large)16 (4xlarge)64 (16xlarge)128
3 nodes
1 node3 (Multi-AZ + Replica)1020 nodes
Active Surcharge Tier:1x Base Extended Support Tier
Monthly Surcharged Compute Volume
70,080 vCPU-hours / month
Annual Extended Support Billed Volume
840,960 vCPU-hours / year
Upgrading to PostgreSQL 16 or 17 reduces Extended Support surcharges to 0 billed vCPU-hours while restoring community CVE patching and modern query planner optimizations.

Upgrade choreography

Three-stage PostgreSQL 17 upgrade choreography

Step through how our engineers run pre-flight extension and collation checks, synchronize a side-by-side PG 17 standby, and execute a controlled cutover with immediate optimizer statistics.

PostgreSQL Major Upgrade Lifecycle

Select a stage to inspect pre-flight checks, replication sync, and cutover verification.

Cluster state & traffic routing

Production snapshot clone -> pg_upgrade --check + amcheck + query plan diff

Phase 1 · Snapshot Clone Audit & Compatibility Verification
  • pg_upgrade --check --link

    Extension & Catalog Check

    Verify PostGIS/pgvector versions, data checksum parity, and reg* data types (PASSED)

  • pg_collation / amcheck

    Collation & Index Audit

    Detect glibc locale version mismatches and verify B-tree sort order integrity (VERIFIED)

  • PUBLIC Schema & SCRAM

    Permissions & Auth

    Pre-grant PG 15+ public schema CREATE rights and test scram-sha-256 clients (READY)

Every extension, OS collation, role permission, and top query plan is validated against PostgreSQL 17 on an isolated clone before touching production.

Representative upgrade runbook deliverable

pg_upgrade --check --link pre-flight, glibc collation audit, and staged ANALYZE

Every upgrade engagement produces a cluster-specific pre-flight and cutover runbook. Below is a representative excerpt showing hard-link pre-flight checks, OS collation mismatch detection, and post-cutover statistics generation.

PostgreSQL 14 to 17 Upgrade Runbook SpecimenSample deliverable

Pre-Flight & Cutover Result

4.8 TB cluster upgraded from PostgreSQL 14 to 17 with hard-links and 90-second staged ANALYZE

Pre-flight auditing caught two legacy md5 service roles, a missing PUBLIC schema CREATE grant for the migration runner, and an outdated PostGIS build. On cutover night, pg_upgrade --link and vacuumdb --analyze-in-stages completed inside a 7-minute maintenance window.

pg_upgrade --link time5m 18s for 4.8 TB
Staged ANALYZE (16 jobs)1m 34s

1. OS glibc collation version mismatch & extension pre-flight SQL

-- Detect OS glibc / ICU collation version drift before upgrading
SELECT collname, collprovider, collversion AS recorded_version,
       pg_collation_actual_version(oid) AS actual_os_version
FROM pg_collation
WHERE collversion IS NOT NULL
  AND collversion <> pg_collation_actual_version(oid);

-- Audit installed extensions against available target versions
SELECT e.extname, e.extversion AS installed_ver, a.default_version AS target_ver
FROM pg_extension e
JOIN pg_available_extensions a ON a.name = e.extname
ORDER BY e.extname;

2. Hard-link pre-flight check & post-cutover staged statistics rebuild

# Pre-flight compatibility check (non-destructive, runs against live or stopped source)
/usr/lib/postgresql/17/bin/pg_upgrade \
  --old-bindir=/usr/lib/postgresql/14/bin \
  --new-bindir=/usr/lib/postgresql/17/bin \
  --old-datadir=/var/lib/postgresql/14/main \
  --new-datadir=/var/lib/postgresql/17/main \
  --link --jobs=8 --check

# Immediately after cutover: regenerate planner histograms in 3 fast passes
/usr/lib/postgresql/17/bin/vacuumdb --all --analyze-in-stages --jobs=16

Ways to engage

Start with an upgrade readiness check, a turnkey upgrade, or ongoing support

Commission a fixed-scope PostgreSQL 16/17 upgrade project, request a free single-instance readiness audit, or pair your upgrade with ongoing Remote DBA and 24x7 support under your service agreement.

Turnkey upgrade projectThis page

End-to-end PG 12/13/14 to 16 & 17 upgrade.

Fixed-scope project covering pre-flight checks, staging rehearsal, query plan regression testing, cutover execution, and post-cutover hypercare.

Upgrade paths we choreograph

  • PG 12/13 EOL exit
  • PG 14/15 to PG 17
  • pg_upgrade --link
  • Logical / Blue-Green
  • Plan regression fixes
Free readiness check

Free 1-instance PG 17 readiness audit.

We inspect your extensions, collations, schema permissions, and deprecated parameters on one PostgreSQL instance and deliver a written upgrade readiness brief.

Checked on one PostgreSQL instance

  • Extension & shared_preload_libraries matrix
  • PUBLIC schema grants & SCRAM auth check
  • Recommended cutover path (link vs logical)
Ongoing lifecycle & EOL cover

EOL Support & Remote DBA Operations.

Need incident coverage on PostgreSQL 12/13/14 while staging your upgrade? Get 15-minute P1 response under a 24x7 support agreement and ongoing DBA care.

  1. 15m P1where contracted
  2. PG 12-17covered in scope
  3. Written RCAafter every P1

PostgreSQL platforms we upgrade across cloud and bare metal

For procurement and security

Mutual NDA first, staging rehearsal before cutover, and explicit rollback gates

We never execute a production PostgreSQL major version upgrade that has not been rehearsed against a clone of your schema and extensions first.Raguraman, Engineering Manager · Allen D, Lead Database SRE
  • Mutual NDA
  • Written upgrade SOW
  • Named senior engineers
  • Rehearsed rollback plan
  • NDA before discovery

    Signed before any catalog or parameter inspection. Initial scoping calls require no database credentials.

  • Written cutover runbook

    Every pre-flight check, cutover command, timing gate, and rollback trigger documented in advance.

  • Least-privilege access

    Read-only pre-flight discovery via your bastion or VPN; elevated maintenance only during approved windows.

  • Runbooks your team keeps

    Your team keeps the complete upgrade runbook, parameter diffs, and updated monitoring queries. Meet the JusDB team.

JusDB's security practices are aligned with ISO 27001 and SOC 2 Type II, and JusDB is pursuing both certifications (see Terms, section 12). Read the stated status.

PostgreSQL major upgrade FAQ

Common questions about PostgreSQL 12, 13 & 14 upgrades to 16 & 17

Answers on EOL dates, RDS Extended Support, PUBLIC schema permissions, glibc collation drift, pg_upgrade --link, and vacuumdb --analyze-in-stages.

When do PostgreSQL 13 and PostgreSQL 14 reach End of Life (EOL) and incur AWS RDS Extended Support?

PostgreSQL 13 reached community End of Life on November 13, 2025, and Amazon RDS standard support for PostgreSQL 13 ended on February 28, 2026 (entering paid Extended Support on March 1, 2026). PostgreSQL 14 reaches community End of Life on November 12, 2026, with AWS RDS standard support ending on February 28, 2027 and Extended Support billing starting March 1, 2027. Upgrading to PostgreSQL 16 (supported through November 2028) or PostgreSQL 17 (supported through November 2029) eliminates Extended Support surcharges.

Can we upgrade directly from PostgreSQL 12, 13, or 14 to PostgreSQL 17 without intermediate hops?

Yes. Both pg_upgrade and native logical replication support direct major version jumps from PostgreSQL 12, 13, or 14 straight to PostgreSQL 16 or 17. However, third-party C extensions such as PostGIS, TimescaleDB, pgvector, and Citus must be audited first: they often require updating the extension to a compatible bridge version on the source cluster before running pg_upgrade or initializing logical replication.

Why do applications fail with 'permission denied for schema public' after upgrading past PostgreSQL 14?

Starting in PostgreSQL 15 (to remediate CVE-2018-1058), the CREATE privilege on the public schema is revoked from PUBLIC by default, and ownership is assigned to pg_database_owner. Any application user or migration runner (Flyway, Liquibase, Prisma, Alembic) that creates objects in public without an explicit GRANT CREATE ON SCHEMA public TO <role> will fail after upgrading from PG 12, 13, or 14. We audit and grant required privileges during pre-flight preparation.

How does OS glibc version drift cause silent B-tree index corruption during a PostgreSQL upgrade?

PostgreSQL B-tree indexes on text, varchar, and char columns using OS collations (such as en_US.UTF-8) rely on the operating system's glibc sort rules. When a physical data directory moves via pg_upgrade or streaming replication onto a newer Linux distribution (for example, upgrading from glibc < 2.28 to a modern OS image), glibc sort order changes beneath existing indexes. That causes silent wrong-row query results and duplicate key errors unless you upgrade via logical replication or run REINDEX DATABASE CONCURRENTLY.

Why do queries slow down immediately after pg_upgrade if vacuumdb --analyze-in-stages is skipped?

pg_upgrade transfers or hard-links heap and index files, but it intentionally does not copy pg_statistic optimizer histograms across major versions. If production traffic hits the upgraded primary before statistics are regenerated, the planner falls back to default guesses and chooses sequential scans. Our runbook immediately runs vacuumdb --all --analyze-in-stages --jobs=N inside the cutover gate to populate histograms in three fast passes.

When should we choose pg_upgrade --link versus Logical Replication or AWS RDS Blue/Green?

Choose pg_upgrade --link when you run self-managed PostgreSQL on the same filesystem and OS image and can accept a 5-to-25-minute maintenance window without doubling storage. Choose Logical Replication or AWS RDS Blue/Green Deployments when you need a sub-minute cutover pause, when you are simultaneously upgrading the underlying Linux OS/glibc version, or when you want a pre-warmed target with zero-copy instant fallback.

What changed in PostgreSQL 16 and 17 for monitoring and vacuum performance?

PostgreSQL 16 introduced pg_stat_io for granular buffer and I/O telemetry and enabled logical replication from standby servers. PostgreSQL 17 replaced the flat array of dead tuple TIDs in VACUUM with a Radix-tree TidStore (cutting vacuum memory usage and lifting the 1GB maintenance_work_mem cap), added native incremental physical backups via pg_basebackup, and moved checkpointer metrics from pg_stat_bgwriter into a dedicated pg_stat_checkpointer view.

What support and SLA coverage do you provide during the upgrade cutover window?

Initial-response targets are 2 to 4 hours during covered business hours, Mon–Fri 09:00–18:00 IST (UTC+5:30). Where your service agreement includes 24x7 on-call, the initial-response target for P1 incidents is 15 minutes. Targets are not resolution guarantees. Standard business hours run 03:30–12:30 UTC. For production upgrade cutovers and post-upgrade hypercare, senior PostgreSQL engineers lead the bridge live, backed by a 15-minute P1 initial-response target under a 24x7 support agreement.

PostgreSQL services & tools

Related PostgreSQL migration, tuning, and operational tracks

Pair your major version upgrade with cloud re-platforming, query plan optimization, or ongoing Remote DBA operations.

Next step

Exit PostgreSQL 12, 13 & 14 EOL without cutover surprises

Tell us your current PostgreSQL version, installed extensions, and allowed maintenance window. The first 30-minute call covers your databases, current ownership, and required coverage. No production access is needed. Or request a free audit of one database instance, subject to availability: mutual NDA before read-only access, a prioritized report within one week after access is ready, and no obligation.

Mutual NDA before access · pre-flight pg_upgrade --check · rehearsed rollback gates

Explore all PostgreSQL services

Need a different PostgreSQL service? Browse our complete offerings.