All Products
Search
Document Center

Data Transmission Service:Configure two-way data synchronization between an RDS PostgreSQL instance and a PolarDB for PostgreSQL cluster

Last Updated:Apr 01, 2026

Data Transmission Service (DTS) supports two-way data synchronization between an ApsaraDB RDS for PostgreSQL instance and a PolarDB for PostgreSQL cluster. This setup is suited for active geo-redundancy and geo-disaster recovery scenarios.

Important

Two-way synchronization requires that each data record be updated on only one of the two nodes. If both nodes update the same record at the same time, DTS responds based on your conflict resolution policy, but data consistency is not guaranteed.

This topic walks you through configuring the forward synchronization task (RDS PostgreSQL to PolarDB for PostgreSQL) and then the reverse task (PolarDB for PostgreSQL to RDS PostgreSQL).

You can follow the same procedure to configure two-way synchronization between a self-managed PostgreSQL database and a PolarDB for PostgreSQL cluster.

Prerequisites

Before you begin, make sure you have:

Billing

Synchronization type Cost
Schema synchronization and full data synchronization Free of charge
Incremental data synchronization Charged. See Billing overview.

How two-way synchronization works

A two-way synchronization instance contains two tasks: a forward synchronization task (RDS PostgreSQL to PolarDB for PostgreSQL) and a reverse synchronization task (PolarDB for PostgreSQL to RDS PostgreSQL).

Circular sync prevention

To prevent changes from looping back indefinitely, DTS creates a schema named dts in both the source and destination databases when a two-way synchronization instance runs. DTS uses this schema to track which changes originated from replication, so those changes are not re-replicated in the reverse direction.

Do not modify the dts schema while the task is running.

DDL synchronization direction

DDL operations are synchronized only in the forward direction (source to destination). DDL operations are ignored in the reverse direction.

Forward and reverse task rules

When both tasks are configured to synchronize the same objects:

  • Only one task (typically the forward task) can synchronize both full data and incremental data. The other task synchronizes incremental data only.

  • Data synchronized by the forward task is not used as source data for the reverse task.

Limitations

Source database limits

Constraint Detail
Primary key or unique key required Tables must have PRIMARY KEY or UNIQUE constraints, with all fields unique. Without this, the destination may contain duplicate records. If you create a task without selecting Schema Synchronization, make sure the destination table has the same PRIMARY KEY or NOT NULL UNIQUE constraints as the source.
Maximum tables per task 5,000 tables per synchronization task when selecting individual tables. For more tables, create multiple tasks or synchronize the entire database.
WAL log retention — incremental only WAL logs must be retained for more than 24 hours.
WAL log retention — full + incremental WAL logs must be retained for at least 7 days. After full data synchronization completes, you can reduce the retention period to more than 24 hours.
Long-running transactions Long-running transactions cause WAL log accumulation, which may exhaust disk space on the source database.
Single data change size If a single incremental data change exceeds 256 MB, the synchronization instance fails and cannot be recovered. You must reconfigure the task.
DDL during schema or full sync Do not execute DDL statements during schema synchronization or full data synchronization.
Major version upgrade Performing a major version upgrade on the source database causes the synchronization instance to fail and cannot be recovered. You must reconfigure the task.

Other limits

Constraint Detail
One database per task A single synchronization task can synchronize data from only one database. Create separate tasks for multiple databases.
Cross-schema inheritance tables DTS cannot synchronize tables with inheritance relationships across schemas.
SERIAL data type If a table contains the SERIAL data type, DTS automatically creates a sequence in the source database. When configuring Source Objects, also select Sequence or use entire schema synchronization.
Foreign keys and triggers During schema synchronization, DTS synchronizes foreign keys from the source database to the destination database. During full data synchronization and incremental data synchronization, DTS sets session_replication_role to replica at the session level during synchronization if the destination account is a privileged account. If the destination account lacks this permission, set session_replication_role to replica manually. After the task is released, reset it to origin. Cascade UPDATE or DELETE operations on the source during this period may cause data inconsistency.
New or renamed tables in a synchronized schema Before writing data to a newly created or renamed table in a synchronized schema, run ALTER TABLE schema.table REPLICA IDENTITY FULL;. Do not lock the table when running this statement. Perform this during off-peak hours.
Temporary tables DTS creates the following temporary tables in the source database. Do not delete them during synchronization — they are automatically removed after the DTS instance is released: public.dts_pg_class, public.dts_pg_attribute, public.dts_pg_type, public.dts_pg_enum, public.dts_postgres_heartbeat, public.dts_ddl_command, public.dts_args_session, public.aliyun_dts_instance.
Heartbeat table DTS adds a heartbeat table named dts_postgres_heartbeat to the source database to maintain latency accuracy.
Replication slot DTS creates a replication slot prefixed with dts_sync_ in the source database to capture incremental logs from the last 15 minutes. The replication slot is automatically deleted when the DTS instance is released. If you change the source database password or remove DTS IP addresses from the allowlist, delete the replication slot manually to prevent accumulation. If a primary/secondary switchover occurs, log on to the secondary database to delete the replication slot.
Sequence validity DTS does not validate sequences. Check sequence validity manually. After switching workloads to the destination database, sequences do not continue from the maximum value in the source. Before switching, query the maximum sequence values in the source and set them as starting values in the destination.
Performance impact Evaluate the impact on source and destination database performance before starting synchronization. Run synchronization during off-peak hours when possible.
Tablespace size After initial full data synchronization, the destination tablespace is larger than the source due to fragmentation from concurrent INSERT operations.
Online DDL If only DTS writes to the destination, you can use DMS to perform online DDL operations on source tables during synchronization. See Change schemas without locking tables. Do not write data from other sources to the destination during synchronization — doing so may cause data loss.
Task failure recovery If a DTS task fails, DTS technical support attempts to restore it within 8 hours. During restoration, the task may be restarted and task parameters (not database parameters) may be modified.

To query maximum sequence values in the source database before switching workloads:

do language plpgsql $$
declare
  nsp name;
  rel name;
  val int8;
begin
  for nsp,rel in select nspname,relname from pg_class t2 , pg_namespace t3 where t2.relnamespace=t3.oid and t2.relkind='S'
  loop
    execute format($_$select last_value from %I.%I$_$, nsp, rel) into val;
    raise notice '%',
    format($_$select setval('%I.%I'::regclass, %s);$_$, nsp, rel, val+1);
  end loop;
end;
$$;
The returned SQL statements cover all sequences in the source database. Run only the statements relevant to your requirements in the destination database.

Special cases

Source database Constraint
ApsaraDB RDS for PostgreSQL Do not modify the endpoint or zone of the instance during synchronization.
Self-managed PostgreSQL The values of max_wal_senders and max_replication_slots must be greater than the sum of existing replication slots in use plus the number of DTS instances needed.
Cloud SQL for PostgreSQL (Google Cloud) Set Database Account to an account with the cloudsqlsuperuser permission. Select only objects the account is authorized to manage, or grant the OWNER permission on the selected objects to the account. A cloudsqlsuperuser account cannot manage data owned by other cloudsqlsuperuser accounts.

Supported conflict detection

DTS detects and responds to three types of conflicts during two-way synchronization:

Conflict type What happens
INSERT uniqueness conflict If a record with the same primary key is inserted on both nodes at nearly the same time, one INSERT fails because the key already exists on the other node.
UPDATE on missing record If the record to update does not exist in the destination, DTS converts the UPDATE into an INSERT. This INSERT may trigger a uniqueness conflict.
DELETE on missing record If the record to delete does not exist in the destination, DTS ignores the DELETE regardless of the conflict resolution policy.

Conflict resolution policies

Select a conflict resolution policy when configuring two-way synchronization:

Policy Behavior
TaskFailed The task reports an error and stops. Resolve the conflict manually before resuming.
Ignore The conflicting statement is skipped. The existing record in the destination is kept.
Overwrite The conflicting record in the destination is overwritten with the source record.
Important

Conflict detection does not prevent all data conflicts. System clock differences and synchronization latency between nodes mean some conflicts may go undetected. To maintain data consistency, make sure each data record is updated on only one node at a time. If you pause and restart a synchronization task, the conflict resolution policy does not apply during the latency window — data in the destination is overwritten by default.

SQL operations that can be synchronized

Operation type SQL statements
DML (data manipulation language) INSERT, UPDATE, DELETE
DDL (data definition language) Forward direction only — DDL is ignored in the reverse direction. See details below.

DDL synchronization details

DDL synchronization applies only to tasks created after October 1, 2020. For tasks created before May 12, 2023, create triggers and functions in the source database before configuring the task. See Use triggers and functions to implement incremental DDL migration for PostgreSQL databases.

BIT type data cannot be synchronized during incremental data synchronization.

When the source database account is a privileged account and the minor engine version of the ApsaraDB RDS for PostgreSQL instance is 20210228 or later, DTS synchronizes the following DDL statements. See Update the minor engine version.

  • CREATE TABLE and DROP TABLE

  • ALTER TABLE, including: RENAME TABLE, ADD COLUMN, ADD COLUMN DEFAULT, ALTER COLUMN TYPE, DROP COLUMN, ADD CONSTRAINT, ADD CONSTRAINT CHECK, ALTER COLUMN DROP DEFAULT

  • TRUNCATE TABLE (source PostgreSQL version 11 or later only)

  • CREATE INDEX ON TABLE

Important

The following DDL operations are not synchronized:

  • DDL statements with CASCADE or RESTRICT

  • DDL statements from sessions that run SET session_replication_role = replica

  • DDL statements executed by invoking functions

  • DDL statements committed at the same time as DML statements

  • DDL statements for objects not included in the synchronization scope

Permissions required for database accounts

Database Required permissions References
ApsaraDB RDS for PostgreSQL Privileged account that is the owner of the database. For RDS PostgreSQL V9.4 with DML-only synchronization, the REPLICATION permission is sufficient. Create an account and Create a database
PolarDB for PostgreSQL cluster Privileged account that is the owner of the database Create a database account and Database management

Key differences between the forward and reverse tasks

Review these differences before you start — the reverse task has specific constraints that differ from the forward task:

Item Forward task Reverse task
Source and destination RDS PostgreSQL to PolarDB for PostgreSQL PolarDB for PostgreSQL to RDS PostgreSQL (directions are swapped)
Instance Region Configurable Fixed — cannot be modified
Selected objects Configure from scratch Cannot reuse the forward task's selected objects
Object name mapping Supported Not recommended — may cause data inconsistency
Conflicting table handling Tables already synced from the forward task are excluded Same
Number of parameters Full set Fewer parameters displayed — configure only what appears in the console

Configure two-way synchronization

Step 1: Open the Data Synchronization page

Use one of the following methods:

DTS console

  1. Log on to the DTS console .

  2. In the left-side navigation pane, click Data Synchronization .

  3. In the upper-left corner, select the region where the synchronization instance will reside.

DMS console

Note

The exact steps may vary based on your DMS console mode and layout. See Simple mode and Customize the layout and style of the DMS console .

  1. Log on to the DMS console .

  2. In the top navigation bar, move the pointer over Data + AI and choose DTS (DTS) > Data Synchronization .

  3. From the drop-down list to the right of Data Synchronization Tasks , select the region where the synchronization instance will reside.

Step 2: Create a task

Click Create Task to go to the task configuration page.

Optional: Click New Configuration Page in the upper-right corner if the page shows Back to Previous Version. Skip this step if Back to Previous Version is already displayed.

Some parameters differ between the new and previous configuration page versions. Use the new version.

Step 3: Configure source and destination databases

Section Parameter Description
N/A Task Name DTS generates a name automatically. Specify a descriptive name to identify the task easily. The name does not need to be unique.
Source Database Select Existing Connection Select a registered database instance from the drop-down list to auto-populate the connection parameters. If the instance is not registered, configure the parameters manually. In the DMS console, use the Select a DMS database instance drop-down list.
Database Type Select PostgreSQL.
Access Method Select Alibaba Cloud Instance.
Instance Region Select the region where the source ApsaraDB RDS for PostgreSQL instance resides.
Replicate Data Across Alibaba Cloud Accounts Select No if both databases are in the same Alibaba Cloud account.
Instance ID Select the source ApsaraDB RDS for PostgreSQL instance.
Database Name Enter the name of the source database to synchronize.
Database Account Enter the database account. See Permissions required for database accounts.
Database Password Enter the account password.
Encryption Select Non-encrypted or SSL-encrypted based on your requirements. For SSL-encrypted connections, upload CA Certificate, Client Certificate, and Private Key of Client Certificate as needed, and enter the Private Key Password of Client Certificate. For a self-managed PostgreSQL database with SSL encryption, upload CA Certificate. For ApsaraDB RDS for PostgreSQL SSL setup, see SSL encryption.
Destination Database Select Existing Connection Select a registered database instance or configure manually.
Database Type Select PolarDB for PostgreSQL.
Access Method Select Alibaba Cloud Instance.
Instance Region Select the region where the destination PolarDB for PostgreSQL cluster resides.
Instance ID Select the destination PolarDB for PostgreSQL cluster.
Database Name Enter the name of the destination database to receive data.
Database Account Enter the database account. See Permissions required for database accounts.
Database Password Enter the account password.

Step 4: Test connectivity and proceed

Click Test Connectivity and Proceed at the bottom of the page.

Make sure the CIDR blocks of DTS servers are added to the security settings of both the source and destination databases. See Add the CIDR blocks of DTS servers. For self-managed databases not set to Alibaba Cloud Instance, click Test Connectivity in the CIDR Blocks of DTS Servers dialog box.

Step 5: Configure objects to synchronize

  1. In the Configure Objects step, set the following parameters:

    Parameter Description
    Synchronization Types Select Schema Synchronization, Full Data Synchronization, and Incremental Data Synchronization. DTS synchronizes historical data first as the basis for subsequent incremental synchronization.
    Synchronization Topology Select Two-way Synchronization.
    Exclude DDL Operations Select Yesalert notification settings to exclude DDL synchronization, or No to include it. DDL operations are synchronized only in the forward direction. This parameter appears only when configuring the forward task.
    Global Conflict Resolution Policy Select the policy for handling conflicts. See Supported conflict detection for details. The policy does not apply during latency windows when you pause and restart a task — data in the destination is overwritten by default during that window.
    Processing Mode of Conflicting Tables Precheck and Report Errors: the precheck fails if the destination contains tables with the same names as source tables. Use Map object names to rename destination tables if they cannot be deleted or renamed. Ignore Errors and Proceed: skips the precheck for identical table names. During full data synchronization, existing destination records with matching primary or unique keys are kept. During incremental synchronization, they are overwritten. If schemas differ, data initialization may fail. Proceed with caution.
    Source Objects Select objects from the Source Objects section and click the arrow icon to move them to the Selected Objects section. You can select columns, tables, or schemas.
    Selected Objects Right-click an object to rename it in the destination (see Map object names), set WHERE filter conditions (see Specify filter conditions), or select which SQL operations to synchronize for that object. Click an object and then click the remove icon to remove it. Note that renaming an object may cause dependent objects to fail synchronization.
  2. Click Next: Advanced Settings and configure the following:

    Parameter Description
    Dedicated Cluster for Task Scheduling By default, DTS uses the shared cluster. To improve stability, purchase a dedicated cluster. See What is a DTS dedicated cluster.
    Retry Time for Failed Connections Time range for retrying failed connections after the task starts. Valid values: 10–1440 minutes. Default: 720 minutes. Set to more than 30 minutes. If DTS reconnects within this window, the task resumes. Otherwise, the task fails. If multiple tasks share the same source or destination database, the shortest retry window applies. DTS charges for the instance during retries.
    Retry Time for Other Issues Time range for retrying failed DDL or DML operations. Valid values: 1–1440 minutes. Default: 10 minutes. Set to more than 10 minutes. This value must be less than Retry Time for Failed Connections.
    Enable Throttling for Full Data Synchronization Limit read/write resource usage during full data synchronization. Configure Queries per second (QPS) to the source database, RPS of Full Data Migration, and Data migration speed for full migration (MB/s). Available only when Full Data Synchronization is selected.
    Enable Throttling for Incremental Data Synchronization Limit resource usage during incremental synchronization. Configure RPS of Incremental Data Synchronization and Data synchronization speed for incremental synchronization (MB/s).
    Environment Tag Tag for identifying the DTS instance. Optional.
    Configure ETL Select Yes to enable extract, transform, and load (ETL) and enter data processing statements. Select No to skip. See What is ETL? and Configure ETL in a data migration or data synchronization task.
    Monitoring and Alerting Select Yes to receive notifications when the task fails or synchronization latency exceeds the threshold. Configure the alert threshold and notification settings. See Configure monitoring and alerting when you create a DTS task. Select No to skip.
  3. Click Next Step: Data Verification to configure data verification. See Configure a data verification task.

Step 6: Save settings and run a precheck

Click Next: Save Task Settings and Precheck at the bottom of the page.

To preview the API parameters for this task, move the pointer over Next: Save Task Settings and Precheck and click Preview OpenAPI parameters before proceeding.

DTS runs a precheck before starting the task. The task starts only after the precheck passes.
If the precheck fails, click View Details next to each failed item, resolve the issue, and click Precheck Again.
If the precheck triggers an alert:
For alerts that cannot be ignored: click View Details, fix the issue, and rerun the precheck.
For alerts that can be ignored: click Confirm Alert Details > Ignore > OK > Precheck Again. Ignoring an alert may cause data inconsistency.

Step 7: Purchase a synchronization instance

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

On the buy page, configure the following:

Section Parameter Description
New Instance Class Billing Method Subscription: pay upfront for a fixed period — more cost-effective for long-term use. Pay-as-you-go: billed hourly — suitable for short-term use. Release the instance when no longer needed to avoid unnecessary charges.
Resource Group Settings The resource group for the synchronization instance. Default: default resource group. See What is Resource Management?
Instance Class Select an instance class based on your required synchronization speed. See Instance classes of data synchronization instances.
Subscription Duration Available only for the Subscription billing method. Options: 1–9 months, 1 year, 2 years, 3 years, or 5 years.

Read and select Data Transmission Service (Pay-as-you-go) Service Terms, then click Buy and Start. In the confirmation dialog box, click OK.

The task appears in the task list. You can monitor its progress there.

Step 8: Wait for the forward task to start running

Wait until the Status of the forward synchronization task changes to Running and initial synchronization is complete.

Step 9: Configure the reverse synchronization task

  1. Find the reverse synchronization task in the task list and click Configure Task in the Actions column.

  2. Configure the reverse task by following Steps 3–6. Apply the constraints from Key differences between the forward and reverse tasks:

    Important

    - Swap source and destination: the source for the reverse task is the destination of the forward task (PolarDB for PostgreSQL), and the destination is the source of the forward task (ApsaraDB RDS for PostgreSQL). - Instance Region is fixed and cannot be changed. - Configure only the parameters that appear in the console — fewer parameters are shown for the reverse task. - Tables already synchronized to the destination by the forward task are excluded from the Processing Mode of Conflicting Tables check in the reverse direction. - Do not reuse the selected objects from the forward task for the reverse task. - Avoid using the object name mapping feature — it may cause data inconsistency.

  3. Wait until Success Rate reaches 100%, then click Back.

Step 10: Verify two-way synchronization is running

Wait until the Status of both the forward and reverse synchronization tasks changes to Running. Two-way data synchronization is now active.

What's next