Docs

Database Transmission Service

Constraints and limits

Constraints and limits (PostgreSQL)

This topic outlines the supported databases and limits when the target database for migration or synchronization is RDS for PostgreSQL, for example, the Volcano Engine RDS for PostgreSQL or self-managed RDS for PostgreSQL.

Supported databases

Source database	Target database	Supported version	Migration type
Volcano Engine RDS for PostgreSQL PostgreSQL connected over public network PostgreSQL connected over express network	Volcano Engine RDS for PostgreSQL PostgreSQL connected over public network PostgreSQL connected over express network	PostgreSQL 11 PostgreSQL 12 PostgreSQL 13 PostgreSQL 14 PostgreSQL 15 PostgreSQL 16 PostgreSQL 17	Schema migration Full migration Incremental migration

Limits

Type	Description
Source database limits	Bandwidth requirements: Adequate egress bandwidth is required on the source database server. Failure to meet this prerequisite will lead to suboptimal migration performance. Tables to be migrated must contain a primary key or unique constraint, and the fields must be unique. Otherwise, duplicate data may occur in the target database. It is recommended that the number of tables in a single task should not exceed 20,000, and the number of databases should not exceed 50. If a large number of tables need to be migrated, it is recommended to split them into multiple tasks. The database or table name of the object to be migrated or synchronized can not contain question marks (?). Otherwise, the task will fail. To perform incremental migration: You must enable WAL logs, that is, set the value of the wal_level parameter to logical. It is recommended that WAL logs be retained for at least 7 days during full migration. Alternatively, wait until the full migration is completed before cleaning up the data logs generated by the source database after the DTS task starts. The account used for data migration must have the following permissions: The source database account needs to have superuser permissions to create logical replication slots. The target database account needs to have permissions to create a schema. If the target database schema already exists, the migration account needs to have the owner permission of the target schema. The following operation limits apply to the source database: During the schema migration and full migration stages, do not perform DDL operations that change the database or table structure, or the data migration task will fail. If only full data migration is performed, do not write new data to the source database, or the source and target data will be inconsistent. To maintain real-time data consistency, it is recommended to select schema migration, full data migration, and incremental data migration.
Other limits	A single data migration task can only migrate one database. To migrate multiple databases, configure a data migration task for each database. During the incremental data migration process, if the granularity of the migration object is schema, ensure that the table-level replication identity REPLICA IDENTITY is set to FULL. If a new table is created in the schema to be migrated, or the table to be migrated is reconstructed using the RENAME command, you need to execute the ALTER TABLE schema.table REPLICA IDENTITY FULL; command before writing data to the table. tip During execution, replace the schema and table in the above command with the actual schema name and table name. During incremental data migration, DTS creates a replication slot with the prefix dts_sync_ in the source database to replicate data. DTS automatically cleans up historical replication slots every 5 to 10 minutes to prevent them from continuously accumulating and taking up disk space. tip When a migration task is released or fails, DTS actively cleans up the replication slot. If a primary/secondary switchover occurs in the Volcano Engine RDS for PostgreSQL, you need to log in to the secondary database to manually clean it up. Prior to executing data migration, assess the performance of both source and target databases. It is also advised to perform the migration during off-peak business hours. Otherwise, during full data migration, DTS consumes certain read/write resources on both source and target databases, which may lead to an increase in database load. Since full data migration performs concurrent insert operations, the table in the target database generates fragments. Therefore, the storage space of the table in the target database will be larger than that of the table in the source database after the full migration is complete. Verify that the character sets of the source and target databases are consistent before migration. Otherwise, pre-check may fail.
Special cases	When the source database is a self-managed RDS for PostgreSQL, if the source database switches to the primary during migration, the task will fail. If the source database performs a restart operation during migration, the migration task will be temporarily interrupted and automatically attempted to recover. If the task does not recover for a long time, submit a ticket for technical support. When migrating PostgreSQL across accounts with incremental migration, initiate the migration task under the source end instance account; the destination can complete the migration via connected over public network. If the source database is Alibaba Cloud PolarDB PostgreSQL and the target database is Volcano Engine RDS for PostgreSQL, when configuring the migration task, ensure that you use the primary endpoint of PolarDB PostgreSQL rather than the cluster endpoint. Otherwise, the migration will fail due to the inability to create a logical replication slot.

Last updated: 2026.02.28 16:10:14