Azure Database for PostgreSQL Adds a Pre-Upgrade Safety Check

Microsoft has opened a public preview of Pre-Upgrade Validation Checks for Azure Database for PostgreSQL, letting IT teams test a major-version upgrade before they ever click the button that starts it. The tool runs inside the existing Upgrade pane in the Azure portal and comes back with a pass or a specific list of blockers to fix first, without touching the live server.

That sounds like a small addition to a settings menu. But Microsoft’s own support forum is full of the exact failures this tool is meant to catch: stuck rollbacks, blocked extensions, connection storms on databases packed with hundreds of individual schemas. Those threads are the real case for why this shipped now, and they also show where a validation pass still cannot save an upgrade.

Why Microsoft Built a Pre-Flight Check for Postgres

Azure Database for PostgreSQL is Microsoft’s managed version of the open-source database, handling patching, backups and scaling so customers do not run their own servers. Major version jumps, say from PostgreSQL 14 to 17, are the riskiest maintenance event on that service because they can break extensions, replication and configuration in ways only visible once the upgrade is already running.

Microsoft’s Postgres team described the old sequence bluntly in its announcement. Issues like unsupported extensions or configuration gaps were discovered only after the upgrade process had already started, which turned routine maintenance into rushed troubleshooting inside a live change window.

With Pre-Upgrade Validation Checks, you can run upgrade checks independently, review actionable results, fix issues, and re-run validation until your server is ready. This shifts upgrade troubleshooting from the upgrade window to a proactive pre-flight step.

That is Microsoft’s own Postgres engineering team, writing on the Microsoft Community Hub. The feature arrived as part of the service’s June 2026 monthly release, with new servers onboarded automatically starting June 5 and existing servers picking it up at their next scheduled maintenance window.

Four Layers of Checks

The validation pass is not a single test. It runs four distinct categories of checks, each targeting a different way an upgrade has historically failed in production.

Microsoft’s documentation on major version upgrades for flexible server lists a recommended 10 to 20 percent of free storage headroom before starting an upgrade, since temporary log files and metadata operations can spike disk usage mid-process. Several extensions, including session_variable, anon, age and pg_duckdb, block every upgrade path outright and must be removed and reinstalled around the event.

The Failures That Made This Necessary

Microsoft’s own Q&A support forum reads like a case file for this feature. One administrator’s May 25 upgrade attempt stalled mid-process, throwing a server busy error that blocked every retry. Microsoft’s team canceled the stuck operation and restored the server to a healthy state, then told the customer their analysis of the root cause would take five days and recommended holding off on any further major-version upgrades in the meantime.

The customer could not wait. According to the thread, they deleted indexes and views on their larger production databases to force a major-version upgrade through, then rebuilt everything by hand and redirected the application to the new instance while working out how to recover data created during the delay.

Extensions caused a separate class of failure. In another documented upgrade attempt from PostgreSQL 14 to 17, the process failed at the precheck stage because the pg_failover_slots extension was still loaded in shared_preload_libraries, a configuration not supported on that upgrade path. Removing it let the same upgrade complete cleanly on the next try.

Scale created its own failure mode. A separate server carrying 266 individual databases failed during the post-upgrade step with a too many SQL connections error, because the connection-handling logic did not scale cleanly with that many databases on one instance.

None of these were exotic setups. They were ordinary production servers hitting ordinary limits, discovered at the worst possible moment: inside the maintenance window itself.

Turning On Validate Only in the Portal

Running the checks does not require new tooling or a support ticket. The workflow sits inside the upgrade experience administrators already use.

1. Open the target flexible server instance in the Azure portal.
2. From the Overview pane, select Upgrade.
3. Choose the target PostgreSQL major version.
4. Select Validate Only instead of starting the actual upgrade.
5. Review the result, download the CSV or server log if issues surface, fix them, and run the check again until it passes.

Validation checks generate their own logs, downloadable from the Server Logs page once logging is enabled on the instance, giving administrators a paper trail to hand to application teams before they schedule real downtime.

Does a Clean Validation Guarantee a Clean Upgrade?

No. A passing validation result confirms the specific conditions Microsoft checks for are clear. It does not guarantee every possible failure mode is covered, and Microsoft’s own documentation is explicit that the checks validate readiness only and never touch the actual upgrade operation.

Some failures documented in Microsoft’s forums sit outside what a compatibility check can catch entirely. One customer trying to move from PostgreSQL 11 to 15 discovered their Azure subscription had no PostgreSQL flexible server compute options available at all in their region, an empty-quota problem that has nothing to do with schema compatibility and everything to do with regional capacity.

• What we know: the checks cover platform prerequisites, extension compatibility, database dependencies and native pg_upgrade output, and results are reviewable and downloadable before any real downtime begins.
• What we know: the feature is public preview only, tied to flexible server, and does not initiate the upgrade or restart the server on its own.
• What’s unconfirmed: Microsoft has not published a general availability date for the feature.
• What’s unconfirmed: how validation behaves on servers still configured with read replicas, since the broader upgrade process requires deleting replicas before the primary server upgrade proceeds.

Regional SKU shortages, connection-handling bugs at scale and mid-upgrade infrastructure hiccups are not schema problems. A clean validation narrows the field of surprises. It does not close it.

Why PostgreSQL Upgrades Are Hard by Design

The difficulty here is not really an Azure problem. PostgreSQL’s own project documentation explains that major releases change internal storage formats, which is why pg_upgrade rewrites system tables in place rather than requiring a full dump and restore of user data.

Peter Eisentraut, a longtime PostgreSQL core contributor, has written that the deeper issue lives in the database’s system catalogs, where the structure of internal tables like pg_attribute is hardcoded into the server itself. Every new feature that needs new catalog fields shifts that hardcoded layout, which is exactly what pg_upgrade has to reconcile between old and new versions.

Azure’s flexible server currently supports PostgreSQL versions 11 through 18, with PostgreSQL 13 having already reached its final community release. That built-in churn, a new major version roughly every year, is why validation tooling matters well beyond any single upgrade cycle. Microsoft moved a comparable preview feature, Premium SSD v2 support for major version upgrades, from preview to general availability in about two months earlier this year. Pre-Upgrade Validation Checks carry no such timeline yet.

Frequently Asked Questions

What Are Pre-Upgrade Validation Checks in Azure Database for PostgreSQL?

They are a public preview feature that tests whether a flexible server instance is ready for a major PostgreSQL version upgrade, checking platform prerequisites, extension compatibility, database dependencies and native pg_upgrade output before any real upgrade begins.

Do Validation Checks Perform the Actual Version Upgrade?

No. Microsoft’s documentation states the checks validate upgrade readiness independently from the actual upgrade operation and do not restart the server or begin the major version upgrade themselves.

Which PostgreSQL Versions Does Azure Database for PostgreSQL Support?

Flexible server currently supports PostgreSQL versions 11 through 18. Version 13.23 was the final community release for PostgreSQL 13, which has already reached end of life, meaning servers still on it should plan an upgrade path soon.

What Extensions Commonly Block a Major Version Upgrade?

Session_variable, anon, age and pg_duckdb block in-place upgrades on every path and must be removed beforehand. Pg_repack, hypopg and pg_partman are non-persistent utility extensions that must be dropped before the upgrade and recreated afterward by design.

How Long Does a Major Version Upgrade Take?

Microsoft support guidance puts typical upgrades at around 15 to 20 minutes, though larger or more complex databases with heavy object counts or unresolved precheck issues have taken a couple of hours in documented cases.

What Happens When a Validation Check Finds a Blocking Issue?

The result includes specific details on what needs remediation, and administrators can fix the issue and re-run the check as many times as needed until it passes, all before scheduling the real maintenance window.