GA: Pre-upgrade Validation Checks for Azure PostgreSQL Flexible Server

What's Changing

Microsoft has announced the General Availability (GA) of pre-upgrade validation checks for Azure Database for PostgreSQL Flexible Server, effective as of August 2026. This feature, previously available in preview, is now production-ready for all supported regions and SKU tiers. It introduces a dedicated Run Validation step inside the Major Version Upgrade (MVU) workflow that lets you assess upgrade readiness — and receive a structured remediation report — before the actual upgrade engine is ever invoked.

Who's Affected & When

This feature is available now, globally, to all Azure Database for PostgreSQL Flexible Server customers. It covers all compute tiers (Burstable, General Purpose, Memory Optimized) and all regions where Flexible Server is generally available. Single Server is explicitly excluded — that service is deprecated and not supported for MVU workflows.

The feature is opt-in at upgrade time — it is not auto-enabled or running silently. You must explicitly trigger validation via the Portal, CLI, PowerShell, or REST API. There is no mandatory-by date; using it before every major version upgrade is strongly recommended practice.

Supported upgrade paths at GA:

What This Means for Your Environment

Major version upgrades for PostgreSQL have historically been a high-risk operation — extension incompatibilities, deprecated data types, open prepared transactions, and active replication slots have each caused production upgrade failures. Pre-upgrade validation runs a structured battery of checks against your live instance and returns a traffic-light report (Passed / Warning / Failed) with actionable remediation steps, all without touching your data or downtime window.

From a practical standpoint, here is what gets checked every time you trigger validation:

• Extension compatibility — PostGIS, pgvector, pg_cron, and others are verified against the target version's extension catalogue.
• Deprecated data types — Types removed in the target version (e.g., abstime removed in PG16) are flagged with affected column names.
• Prepared transactions — Any open pg_prepared_xacts entries will block the upgrade engine and are reported.
• Replication slots — Active logical replication slots must be dropped before upgrade; the report names each slot.
• Parameter compatibility — Settings like max_connections and shared_buffers are cross-checked against target version defaults.
• Encoding and locale — Mismatches between database encoding, collation, and OS locale are surfaced.
• System catalog consistency — Internal catalog integrity is verified before upgrade metadata is written.

Action Items

Here is what you should do right now if you manage Azure Database for PostgreSQL Flexible Server instances:

1. Identify servers approaching end-of-support version lifecycles
   PostgreSQL 11 is past EOL. PostgreSQL 12 reaches EOL in November 2024. Audit all Flexible Server instances for their current major version via the Azure Portal or CLI:
   

   # List all PostgreSQL Flexible Servers and their versions across a subscription
   az postgres flexible-server list \
     --query "[].{Name:name, RG:resourceGroup, Version:version, State:state}" \
     --output table

2. Run pre-upgrade validation before any planned upgrade window
   Do this at least one week before your scheduled maintenance window to allow time for remediation. Use the CLI flag --pre-upgrade-validate-only true to trigger validation without committing to the upgrade:
   

   # Validate upgrade to PostgreSQL 16 without performing the upgrade
   az postgres flexible-server upgrade \
     --resource-group myRG \
     --name myPostgresServer \
     --version 16 \
     --pre-upgrade-validate-only true

3. Export and archive the validation report
   In the Portal, export the report as JSON or CSV after each validation run. This provides an audit trail for change management boards and compliance reviews.
4. Resolve blocking failures before your maintenance window
   The most common blockers in production are active replication slots and incompatible extensions. Coordinate with application teams early — dropping a replication slot impacts downstream subscribers. Check open prepared transactions:
   

   -- Check for open prepared transactions that block upgrade
   SELECT gid, prepared, owner, database FROM pg_prepared_xacts;
   
   -- Commit or rollback each one before proceeding
   COMMIT PREPARED 'your_transaction_id';

5. Verify RBAC permissions for the team running upgrades
   The account triggering validation and upgrade must have the Contributor or Owner role on the Flexible Server resource, or the built-in Azure Database for PostgreSQL Flexible Server Contributor role. Least-privilege setups should use the built-in role.
6. Update tooling to minimum supported versions
   The --pre-upgrade-validate-only parameter requires Azure CLI 2.56.0 or later. The PowerShell equivalent requires Az.PostgreSql 1.1.0 or later. Run az version and Get-InstalledModule Az.PostgreSql to confirm.

The GA of pre-upgrade validation removes the single biggest reason teams defer PostgreSQL major version upgrades: fear of unknown failures mid-window. Run it, fix what it finds, and upgrade with confidence.