• Amazon RDS 9.6.10+, 10.5+, 11.1+, 12, 13, 14, 15, 16, 17.
• Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14.6+, 15.2+, 16, 17.
• Self-managed PostgreSQL (on premises or on any cloud VM that you fully control) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16, 17.
• Cloud SQL for PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17.
• Microsoft Azure Database for PostgreSQL Flexible Server: 11+

• Cloud SQL for PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17.

• All schemas and all tables from the selected database.

• Naming
• Primary key
• Data type
• Ordinal position
• Default value
• Nullability
• Auto-increment attributes
• Secondary indexes

• Stored Procedures
• Functions
• Triggers
• Views
• Foreign key constraints

1. Stop writes to the source and run the DDL commands in both the source and the destination. Beforerunning DDL commands on the destination, grant thecloudsqlexternalsync role to the Cloud SQL user applyingthe DDL changes. To enable querying or changing the data, grant thecloudsqlexternalsync role tothe relevant Cloud SQL users.

2. Use thepglogical.replicate_ddl_command to run DDL on the source and destination at a consistent point. The user running this command must have the same username on both the source and the destination, and should be the superuser or the owner of the artifact being migrated (for example, the table, sequence, view, or database).

   Here are a few examples of using thepglogical.replicate_ddl_command.

   To add a column to a database table, run the following command:

   select pglogical.replicate_ddl_command('ALTER TABLE[schema].[table] add column surname varchar(20)', '{default}');

   To change the name of a database table, run the following command:

   select pglogical.replicate_ddl_command('ALTER TABLE[schema].[table] RENAME TO[table_name]','{default}');

   To create a database table, run the following commands:

   1. select pglogical.replicate_ddl_command(command := 'CREATE TABLE[schema].[table] (id INTEGER PRIMARY KEY, name VARCHAR);', replication_sets := ARRAY['default'']);
   2. select pglogical.replication_set_add_table('default', '[schema].[table]');

To add users to the Cloud SQL destination instance, navigate to the instance and add users from theUsers tab, or add them from the PostgreSQL client. Learn more aboutcreatingand managing PostgreSQL users.

Large objects can't bereplicated because PostgreSQL's logical decoding facility doesn'tsupport decoding changes to large objects. For tables that havecolumn type oid referencing largeobjects, the rows are still synced, and new rows are replicated. However, trying to accessthe large object on the destination database(read usinglo_get,export usinglo_export, or check the catalogpg_largeobject for the given oid), fails with a message saying that the large object doesn't exist.

For tables that don't have primary keys, Database Migration Service supports migration of theinitial snapshot andINSERT statements during the change data capture (CDC) phase. You should migrateUPDATE andDELETE statements manually.

Database Migration Service doesn't migrate data from materialized views, just the view schema. To populate the views, run the following command:REFRESH MATERIALIZED VIEWview_name.

TheSEQUENCE states (for example,last_value) on the new Cloud SQL destination might vary from the sourceSEQUENCE states.