In-place major version upgrade for Azure Database for PostgreSQL Elastic Clusters (v16 → v17)?

Hi @Aashay Thakkar
Thank you for the update - glad to hear you are actively working on this. Let me address your questions on Azure DMS and other migration options directly.

Azure Database Migration Service (DMS) - Does it work for this use case?

Azure DMS supports online (minimal downtime) migrations for Azure Database for PostgreSQL, but its primary supported scenario is migrating into Azure Database for PostgreSQL Flexible Server. For Elastic Cluster as a target, DMS support is limited and not the recommended path for an Elastic Cluster → Elastic Cluster migration.

Given that your cluster is single-node with no Citus distributed/sharding features, your workload is effectively standard PostgreSQL - which means all standard PostgreSQL migration tooling applies cleanly. This is actually the simplest migration scenario possible for Elastic Clusters.

Supported migration options (recommended order):

Option 1 - Logical Replication (minimal downtime, recommended)

This is the best approach if you need to minimize downtime. It keeps the v16 cluster live while data is continuously replicated to the v17 cluster, and you cut over when ready.

On the source (v16 cluster):

• Set wal_level = logical
  • Set max_replication_slots and max_wal_senders to at least the number of databases being replicated
  • Create a publication: CREATE PUBLICATION migration_pub FOR ALL TABLES;

On the target (v17 cluster):

• Create the schema first (use pg_dump --schema-only to extract and apply it)
  • Create a subscription: CREATE SUBSCRIPTION migration_sub CONNECTION 'host=<v16-host> port=5432 dbname=<dbname> user=<replication-user> password=<password>' PUBLICATION migration_pub;
  • Monitor replication lag until it reaches near-zero
  • Stop writes to v16, confirm lag = 0, then cut over application connections to v17
  • Drop the subscription and publication after cutover

Note: Logical replication does not replicate DDL changes — schema must be in sync before the subscription is created. Sequences also need to be manually synchronized at cutover.

Option 2 - pg_dump / pg_restore (simpler, requires downtime)

This is the straightforward approach if a maintenance window is acceptable.

Step 1 - Dump from v16 cluster

pg_dump -h <v16-host> -U <admin-user> -d <database-name> -Fc -f backup_v16.dump

Step 2 - Restore to v17 cluster

pg_restore -h <v17-host> -U <admin-user> -d <database-name> -Fc backup_v16.dump

For multiple databases, repeat per database. pg_dump is version-safe — a v16 dump restores cleanly to v17.

Option 3 - pg_dumpall (for globals + all databases)

If you need to migrate roles, tablespaces, and all databases in one pass:

Dump everything including globals

pg_dumpall -h <v16-host> -U <admin-user> > full_backup.sql

Restore to v17

psql -h <v17-host> -U <admin-user> -f full_backup.sql

Pre-migration checklist (important for Elastic Cluster):

1. Provision the new v17 Elastic Cluster with the same compute/storage tier as your v16 cluster before starting migration.
2. Recreate any firewall rules and VNet integration settings on the v17 cluster.
3. Extensions — run on v16 first: SELECT * FROM pg_extension; Ensure all extensions used are available and compatible on PostgreSQL 17. Most common ones (pgvector, pg_stat_statements, etc.) are supported on v17.
4. Test the application against the v17 cluster before cutting over production traffic.
5. Update connection strings in your application to point to the v17 cluster endpoint after cutover.

Recommendation for your situation:

Given you are single-node with no Citus features, Option 1 (logical replication) gives you the cleanest migration with minimal downtime if your dataset is large. Option 2 (pg_dump/restore) is perfectly fine if you can tolerate a maintenance window - it is simpler to execute and validate.

Reference:

• Upgrade Azure Database for PostgreSQL with Minimal Downtime Using Logical Replication
• Logical replication and logical decoding in Azure Database for PostgreSQL flexible server
• Major version upgrades in Azure Database for PostgreSQL flexible server
• Migrate Azure Cosmos DB for PostgreSQL to an existing Azure Database for PostgreSQL elastic cluster
• Upgrade cluster in Azure Cosmos DB for PostgreSQL
• January 2026 Recap: Azure Database for PostgreSQL

I hope this help. Please let us know which approach you would like to proceed with and we can provide more detailed guidance for your specific configuration.