Configure your destination AlloyDB for PostgreSQL database

Database Migration Service supports continuous migrations from Oracle source databases to the following AlloyDB for PostgreSQL destination databases:

AlloyDB for PostgreSQL 14, 15

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

Creating an AlloyDB for PostgreSQL cluster and a primary instance. We recommend that your primary instance has at least 4vCPU and 32GB of memory.
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
- CREATE DATABASE
- SELECT
- INSERT
- UPDATE
- DELETE
- TRUNCATE (for all tables)
(For databases that contain foreign keys or triggers) Skip foreign keys and triggers by using the REPLICATION option with your migration user account. Run the following command:
```
    ALTER USER MIGRATION_USER_NAME WITH replication;
    
```
For more information on how foreign keys and triggers are migrated, see Considerations for foreign keys and triggers.

Considerations for foreign keys and triggers

Foreign keys and triggers present in your source database might lead to data integrity issues, or even cause the migration job to fail. You can prevent these issues if you skip foreign keys and triggers by using the REPLICATION option for the migration user. Alternatively, you can also drop all foreign keys and triggers in the destination database and re-create them when the migration is complete.

Triggers: Data replicated by Database Migration Service already incorporates any changes made by triggers on the source database. If triggers are enabled on the destination, they can fire again and potentially manipulate data, resulting in data integrity or duplication issues.
Foreign keys: Database Migration Service doesn't replicate data in a transactional manner, so tables might be migrated out of order. If foreign keys are present, and a child table that uses a foreign key is migrated before its parent, you might encounter replication errors.