All Products
Search

This Product

    Data Transmission Service:Migrate data from an RDS MySQL instance to an RDS PostgreSQL instance

    Document Center

    Data Transmission Service:Migrate data from an RDS MySQL instance to an RDS PostgreSQL instance

    Last Updated:Mar 30, 2026

    Data Transmission Service (DTS) migrates data from an ApsaraDB RDS for MySQL instance to an ApsaraDB RDS for PostgreSQL instance with minimal downtime. This guide covers schema migration, full data migration, and incremental data migration.

    Prerequisites

    Before you begin, make sure you have:

    Billing

    Migration type Instance configuration fee Internet traffic fee
    Schema migration and full data migration Free Charged when the destination Access Method is set to Public IP Address. See Billing overview.
    Incremental data migration Charged. See Billing overview.

    Migration types

    DTS supports three migration types for this scenario:

    • Schema migration — Migrates the schemas of selected objects from the source to the destination. DTS transfers foreign keys during this phase.

    • Full data migration — Migrates all existing data in the selected objects from the source to the destination.

    • Incremental data migration — After full data migration completes, continuously syncs new changes from the source to the destination. This keeps the destination current while your application continues writing to the source, enabling a near-zero-downtime cutover. DTS syncs the following DML operations: INSERT, UPDATE, and DELETE.

    Limitations

    Source database requirements

    • Tables must have a PRIMARY KEY or UNIQUE constraint with all fields unique. Without this, the destination may contain duplicate records.

    • If you rename tables or columns during migration, a single task supports up to 1,000 tables. For more than 1,000 tables, run multiple tasks in batches or migrate the entire database without renaming.

    • Binary logging must be configured correctly on the source instance:

      • Binary logging must be enabled. The binlog_format parameter must be set to row, and binlog_row_image must be set to full. See View the parameters of an ApsaraDB RDS for MySQL instance. Incorrect settings cause the precheck to fail.

      • For incremental data migration only: retain binary logs for more than 24 hours.

      • For full data migration plus incremental data migration: retain binary logs for at least seven days. After full data migration completes, you can reduce the retention period to more than 24 hours. Insufficient retention causes DTS to fail to read binary logs, which may result in task failure or data loss, and voids the Service Level Agreement (SLA). See Manage binary log files.

    • During schema migration, do not run DDL operations that change database or table schemas. This causes the migration task to fail.

    Other limitations

    • Do not use tools such as pt-online-schema-change to run DDL operations on migrated objects while the task is running. This may cause the migration to fail.

    • For columns of the FLOAT or DOUBLE data type, DTS retrieves values using ROUND(COLUMN,PRECISION). If you do not specify a precision, DTS defaults to 38 digits for FLOAT and 308 digits for DOUBLE. Verify that these defaults meet your requirements before starting the migration.

    • Run migrations during off-peak hours. Full data migration consumes read and write resources on both the source and destination, increasing load on both database servers.

    • After full data migration, the destination tablespace will be larger than the source. Concurrent INSERT operations during full data migration cause table fragmentation on the destination.

    • During full and incremental migrations, DTS suspends constraint checks and foreign key cascade operations at the session level. If cascade updates or deletions occur in the source while the task is running, data inconsistencies may result.

    • DTS automatically retries failed tasks for up to seven days. Before switching your application to the destination, stop or release the migration task — or run REVOKE to remove write permissions from the DTS database account. Otherwise, DTS may overwrite destination data when it retries.

    Required permissions

    Source ApsaraDB RDS for MySQL instance

    Migration type Required permissions
    Schema migration SELECT
    Full data migration SELECT
    Incremental data migration REPLICATION SLAVE, REPLICATION CLIENT, SHOW VIEW, SELECT

    For instructions on creating an account and granting permissions, see Create an account and Modify account permissions.

    Destination ApsaraDB RDS for PostgreSQL instance

    Migration type Required permissions
    Schema migration CREATE and USAGE on migrated objects
    Full data migration Schema owner permissions
    Incremental data migration Schema owner permissions

    For instructions on creating an account, see Create an account.

    Create a migration task

    1. Log on to the Data Management (DMS) console. In the top navigation bar, click DTS. In the left-side navigation pane, choose DTS (DTS) > Data Migration.

      You can also go directly to the Data Migration Tasks page.

    2. From the drop-down list next to Data Migration Tasks, select the region where your migration instance resides.

      In the new DTS console, select the region from the top navigation bar instead.

    3. Click Create Task. In the Create Data Synchronization Task wizard, configure the source and destination databases.

      Source database settings:

      Parameter Value
      Task Name Enter a descriptive name. DTS auto-generates one, but a meaningful name makes the task easier to identify. Names do not need to be unique.
      Database Type MySQL
      Access Method Alibaba Cloud Instance
      Instance Region The region of the source ApsaraDB RDS for MySQL instance
      Replicate Data Across Alibaba Cloud Accounts Select No for same-account migrations
      RDS Instance ID The ID of the source ApsaraDB RDS for MySQL instance
      Database Account The database account for the source instance
      Database Password The password for the database account
      Encryption Select Non-encrypted or SSL-encrypted based on your requirements. To use SSL encryption, enable it on the RDS for MySQL instance first. See Use a cloud certificate to enable SSL encryption.

      Destination database settings:

      Parameter Value
      Database Type PostgreSQL
      Access Method Alibaba Cloud Instance
      Instance Region The region of the destination ApsaraDB RDS for PostgreSQL instance
      Instance ID The ID of the destination ApsaraDB RDS for PostgreSQL instance
      Database Name The database in the destination instance that will receive the migrated objects
      Database Account The database account for the destination instance
      Database Password The password for the database account

    4. Click Test Connectivity and Proceed.

      Warning

      DTS automatically adds its server CIDR blocks to the whitelist of Alibaba Cloud database instances, or to the security group rules of Elastic Compute Service (ECS) instances hosting self-managed databases. For self-managed databases in data centers or hosted by third-party providers, manually add the DTS CIDR blocks. See Add the CIDR blocks of DTS servers to the security settings of on-premises databases. Adding DTS CIDR blocks introduces security exposure. Take precautions such as enforcing strong passwords, limiting exposed ports, auditing API calls, and regularly reviewing whitelist entries. Alternatively, connect to DTS using Express Connect, VPN Gateway, or Smart Access Gateway. After the migration task completes or is released, remove the DTS CIDR blocks from the whitelist or security group rules.

    5. Configure the objects to migrate and advanced settings.

      Basic settings:

      Parameter Description
      Synchronization Types Select the migration types to run: Schema Migration, Full Data Migration, and optionally Incremental Data Migration. To migrate without interrupting your application, select all three. If you skip Schema Migration, create the required tables and schemas in the destination first. If you skip Incremental Data Migration, stop all writes to the source database during migration to ensure data consistency.
      Processing Mode of Conflicting Tables Precheck and Report Errors (default): fails the precheck if the destination has tables with the same names as the source. Use object name mapping to rename conflicting tables if they cannot be deleted. Ignore Errors and Proceed: skips this check. During full data migration, existing records with matching primary keys are kept; during incremental data migration, they are overwritten. Use with caution.
      Capitalization of Object Names in Destination Instance Controls the capitalization of database, table, and column names in the destination. The default is DTS default policy. See Specify the capitalization of object names in the destination instance.
      Source Objects Select objects from Source Objects and click Rightwards arrow to move them to Selected Objects. Note: TIMESTAMP values of 0 in the source are converted to null in the destination.
      Selected Objects To rename a single object, right-click it. To rename multiple objects at once, click Batch Edit. See Map object names. Note: renaming an object may cause dependent objects to fail migration.

      Advanced settings:

      Parameter Description
      Monitoring and Alerting Select Yes to receive notifications when the task fails or migration latency exceeds a threshold. Configure the alert threshold and notification settings. See Configure monitoring and alerting.
      Retry Time for Failed Connections The time range DTS waits before marking a failed connection as unrecoverable. Valid values: 10–1,440 minutes. Default: 120 minutes. Set to at least 30 minutes. If DTS reconnects within this window, the task resumes automatically. Note: if multiple tasks share the same source or destination, the most recently configured retry time applies to all. DTS charges for the instance during retries.
      Configure ETL Select Yes to enable extract, transform, and load (ETL) processing. Enter data processing statements in the code editor. See Configure ETL in a data migration or data synchronization task.

    6. Click Next: Save Task Settings and Precheck.

      DTS runs a precheck before starting the migration. The task cannot start until it passes. If the precheck fails, click View Details next to each failed item, resolve the issues, then click Precheck Again. If an alert is triggered: for non-ignorable alerts, resolve the issue and recheck. For ignorable alerts, click Confirm Alert Details, then Ignore, then OK, then Precheck Again. Ignoring alerts may result in data inconsistency.

    7. Wait until the Success Rate reaches 100%, then click Next: Purchase Instance.

    8. On the Purchase Instance page, configure the instance class.

      Parameter Description
      Resource Group The resource group for the migration instance. Default: default resource group. See What is Resource Management?
      Instance Class The instance class determines migration speed. See Instance classes of data migration instances for options.

    9. Read and select Data Transmission Service (Pay-as-you-go) Service Terms.

    10. Click Buy and Start. In the confirmation dialog, click OK.

    The task appears on the Data Migration page, where you can monitor its progress.