Configure your destination Cloud SQL for PostgreSQL database

Overview

Database Migration Service supports continuous migrations from source databases to Cloud SQL destination databases.

Supported destination databases for Cloud SQL for PostgreSQL include versions:

Before you can use Database Migration Service to migrate data into your destination database, you must configure the database by:

Creating an instance. We recommend a machine type with at least a dual-core CPU. For example, if your machine name is db-custom, and it has 2 CPUs and 3840 MB of RAM, then the format for the machine type name is db-custom-2-3840.
If you connect to the destination instance using a public IP address, Database Migration Service uses Cloud SQL Auth proxy to connect to the instance. This requires the following:
- The instance must have a public IPv4 address.
- The public IP address doesn't need to be accessible to any external address (it doesn't have to be added as an authorized network address).
If you connect to the destination instance using a private IP address, Database Migration Service uses Private Service Connect to connect to the instance. For more information, see Configure Private Service Connect for a destination instance.
Creating a user account and database in the instance with the same name. For example, if you're using Database Migration Service to migrate data into the myapp database, then the name of the user account should also be myapp.
Setting the following permissions for the user on the database:
- CREATE SCHEMA
- CREATE TABLE
- SELECT
- INSERT
- UPDATE
- DELETE
- TRUNCATE (for all tables)

We recommend performing the following steps to avoid performance and data integrity issues:

Disable all foreign key constraints and indexes in the destination Cloud SQL for PostgreSQL database, and enable them back when the migration is completed. Foreign keys don't block the migration but they affect its overall performance.
Disable all triggers in the destination Cloud SQL for PostgreSQL database, and enable them back when the migration is completed. Triggers enabled in the destination database might result in data differences between the source and destination.