PolarDB:FAQ

Pre-migration checklist

Before starting the upgrade, confirm the following:

• SSL and TDE: If your source ApsaraDB RDS for PostgreSQL instance has SSL or transparent data encryption (TDE) enabled, you cannot migrate to a PolarDB for PostgreSQL cluster (DES architecture).

• Cross-version upgrade: If you need to upgrade across major PostgreSQL versions (for example, from PostgreSQL 10 to PostgreSQL 14), use the logical migration method. Smooth migration does not support cross-version upgrades.

• Node specifications: Choose specifications equal to or higher than those of the source instance to avoid performance degradation after the switchover. Matching specifications exactly is not required.

Do I need to purchase a PolarDB cluster before starting the upgrade?

No. During the upgrade process, you purchase and create the destination PolarDB for PostgreSQL cluster at the same time — with data already cloned from the source instance.

Does migration affect the source ApsaraDB RDS for PostgreSQL instance?

Data migration does not affect operations on the source instance. However, because migration involves read operations, query performance on the source instance may be slightly affected during migration.

What happens to my workloads during smooth migration?

Smooth migration guarantees no data loss. Service downtime does not exceed 10 minutes. During downtime, the service is suspended and no incremental data is generated, but the database itself remains active. Rollback is supported if needed.

Is there an existing DTS task on the source instance — will migration break it?

No. During migration, full data is cloned from the source ApsaraDB RDS for PostgreSQL instance to the new PolarDB cluster, and incremental data is synchronized in real time. The source instance remains the data source or destination of the Data Transmission Service (DTS) task throughout.

After you switch services to the new PolarDB cluster and stop using the source instance, the DTS task's data source is not automatically updated. Create a new DTS synchronization task and set the data source to the PolarDB cluster.

What happens if I cancel the migration?

Canceling the migration has the following effects:

• The synchronization link from the source instance to the destination cluster is disconnected, and the source instance is no longer associated with the destination cluster.

• The destination cluster becomes readable and writable but is not automatically released.

Do I need to update application connection strings after the switchover?

If you selected Switch with Endpoints (Connection Changes Not Required) during the switchover, the system automatically exchanges endpoints between the source ApsaraDB RDS for PostgreSQL instance and the destination PolarDB cluster. No application reconfiguration is needed.

I selected "Switch with Endpoints" but still need new endpoints — why?

Endpoint exchange only works when both the source instance and the destination cluster have the corresponding endpoint types. By default, only the primary endpoints on the internal network are exchanged.

To exchange other endpoint types (such as public endpoints or custom endpoints), create those endpoints before the switchover:

• PolarDB endpoint: View or apply for an endpoint

• RDS endpoint: Configure endpoints for an RDS instance

Can I also exchange read-only instance endpoints?

Yes, if the destination PolarDB cluster has cluster endpoints and custom endpoints configured. When those exist, you can exchange read-only instance endpoints alongside the primary endpoint during the Switch with Endpoints (Connection Changes Not Required) operation.

Connections or writes are failing after the switchover — what's wrong?

After endpoint exchange, DNS cache expiration can cause connection failures or make the database temporarily read-only. Refresh the DNS cache on the affected clients to restore connectivity.

The "Complete Migration" button is missing from the console — why?

The Complete Migration button is hidden after the Complete Migration step has been completed, to prevent the step from running again.

Do I need to recreate accounts, passwords, and databases in the destination cluster?

No. The destination PolarDB cluster automatically inherits accounts, passwords, databases, IP address whitelists, and required parameters from the source ApsaraDB RDS for PostgreSQL instance.