As limitações conhecidas para usar uma base de dados PostgreSQL como origem incluem:
A extensão pglogical não suporta a replicação de colunas geradas para o PostgreSQL 12 ou superior.
As alterações às estruturas das tabelas (LDD) não são replicadas através de comandos LDD padrão, mas apenas com comandos executados através da extensão pglogical usada para replicação. Isto inclui
alterações aos
enum tipos.
Por exemplo, pglogical fornece uma função
pglogical.replicate_ddl_command que permite executar DDL na
base de dados de origem e na réplica num ponto consistente. O utilizador que executa este comando na origem já tem de existir na réplica.
Para replicar dados para novas tabelas, tem de usar o comando pglogical.replication_set_add_table para adicionar as novas tabelas a conjuntos de replicação existentes.
Para saber mais sobre a replicação de DDL enquanto a migração está em curso, consulte a secção sobre a fidelidade da migração.
Para tabelas que não têm chaves principais, o Database Migration Service suporta a migração da imagem instantânea inicial e das declarações INSERT durante a fase de captura de dados de alterações (CDC). Deve migrar as declarações UPDATE e DELETE manualmente.
O Database Migration Service não migra dados de vistas materializadas, apenas o esquema de vistas. Para preencher as vistas, execute o seguinte comando: REFRESH MATERIALIZED VIEW view_name.
Os estados SEQUENCE (por exemplo, last_value) no novo destino do AlloyDB podem variar em relação aos estados SEQUENCE de origem.
As tabelas UNLOGGED e TEMPORARY não são replicadas e não podem ser replicadas.
O tipo de dados de objeto grande não é suportado. Mais detalhes na secção sobre a
fidelidade da migração.
O serviço de migração de bases de dados não suporta a migração a partir de réplicas de leitura que estejam no modo de recuperação.
O serviço de migração de base de dados não suporta origens do Amazon RDS onde o pacote de extensão do AWS SCT é aplicado.
As funções definidas pelo utilizador escritas em C não podem ser migradas, exceto as funções instaladas na base de dados PostgreSQL quando instala extensões suportadas pelo AlloyDB.
Se existirem outras extensões e linguagens processuais na base de dados de origem ou se as respetivas versões não forem suportadas, o teste ou o trabalho de migração falham.
As bases de dados adicionadas após o início da tarefa de migração não são migradas.
Não pode selecionar tabelas nem esquemas específicos quando migra através do serviço de migração de bases de dados.
O Database Migration Service migra todas as tabelas e esquemas, exceto os seguintes:
O esquema de informações (information_schema).
Todas as tabelas que começam por pg, por exemplo, pg_catalog. Para ver a lista completa de catálogos do PostgreSQL que começam por pg, consulte Catálogos do sistema PostgreSQL na documentação do PostgreSQL.
As informações sobre os utilizadores e as funções de utilizador não são migradas.
Se as bases de dados encriptadas exigirem chaves de encriptação geridas pelo cliente para desencriptar as bases de dados e se o Database Migration Service não tiver acesso às chaves, não é possível migrar as bases de dados.
No entanto, se os dados de clientes estiverem encriptados pela extensão pgcrypto, podem ser migrados com o serviço de migração de bases de dados (porque o AlloyDB suporta a extensão).
O serviço de migração de bases de dados também suporta a migração de dados de bases de dados Amazon Aurora ou Amazon RDS encriptadas, uma vez que estas bases de dados processam a desencriptação de forma transparente nos respetivos serviços. Para mais informações, consulte os artigos Encriptar recursos do Amazon Aurora e Encriptar recursos do Amazon RDS.
A base de dados AlloyDB de destino é
gravável durante a migração
para permitir que as alterações de DDL sejam aplicadas, se necessário. Tenha cuidado para não fazer alterações à configuração da base de dados nem às estruturas das tabelas que possam interromper o processo de migração ou afetar a integridade dos dados.
O comportamento do acionador depende da forma como foram configurados. Por predefinição, não são acionados, mas, se tiverem sido configurados através da declaração ALTER EVENT TRIGGER ou ALTER TABLE e o estado do acionador estiver definido como réplica ou sempre, são acionados na réplica durante a replicação.
As funções com o definidor de segurança são criadas por
alloydbexternalsync no AlloyDB primário. Quando é executado por qualquer utilizador, é executado com os privilégios de alloydbexternalsync, que tem as funções alloydbsuperuser e alloydbreplica. É melhor restringir a utilização de uma função de definidor de segurança apenas a alguns utilizadores. Para tal, o utilizador deve revogar os privilégios PUBLIC predefinidos e, em seguida, conceder o privilégio de execução seletivamente.
Limitações para migrações para clusters de destino existentes
O cluster de destino existente tem de estar vazio ou conter apenas dados de configuração do sistema. A migração para um cluster de destino existente
que contenha dados do utilizador (como tabelas) não é suportada.
Só pode configurar uma tarefa de migração por cluster de destino.
A migração para clusters com clusters secundários não é suportada.
A migração para clusters com instâncias de banco de dados de leitura é suportada.
Podem existir até 2000 perfis de ligação e 1000 tarefas de migração em qualquer altura. Para criar espaço para mais, pode eliminar tarefas de migração (incluindo as concluídas) e perfis de ligação.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-21 UTC."],[[["\u003cp\u003eDatabase Migration Service supports the migration of initial snapshots and \u003ccode\u003eINSERT\u003c/code\u003e statements for tables without primary keys, but \u003ccode\u003eUPDATE\u003c/code\u003e and \u003ccode\u003eDELETE\u003c/code\u003e statements must be manually migrated.\u003c/p\u003e\n"],["\u003cp\u003eCertain PostgreSQL features are not supported during migration, including \u003ccode\u003eUNLOGGED\u003c/code\u003e and \u003ccode\u003eTEMPORARY\u003c/code\u003e tables, Large Object data types, and read replicas in recovery mode.\u003c/p\u003e\n"],["\u003cp\u003eDatabase Migration Service migrates all tables and schemas except for \u003ccode\u003einformation_schema\u003c/code\u003e and tables beginning with \u003ccode\u003epg\u003c/code\u003e, and does not migrate information about users and user roles.\u003c/p\u003e\n"],["\u003cp\u003eWhile the destination AlloyDB database remains writable during migration, modifications to the database configuration or table structures should be avoided to prevent issues.\u003c/p\u003e\n"],["\u003cp\u003eThere are quotas for the amount of migration jobs and connection profiles that can exist at any given time, set to 1,000 and 2,000 respectively, requiring deletion to create space for more.\u003c/p\u003e\n"]]],[],null,["# Known limitations\n\n\u003cbr /\u003e\n\n[MySQL](/database-migration/docs/mysql/known-limitations \"View this page for the MySQL version of Database Migration Service.\") \\| [PostgreSQL](/database-migration/docs/postgres/known-limitations \"View this page for the PostgreSQL version of Database Migration Service.\") \\| PostgreSQL to AlloyDB\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nKnown limitations for using a PostgreSQL database as a source include:\n\n- The `pglogical` extension doesn't support the replication of [generated columns](https://www.postgresql.org/docs/current/ddl-generated-columns.html) for PostgreSQL 12+.\n\n- Changes to table structures (DDL) aren't replicated through standard DDL\n commands, but only with commands executed using the `pglogical`\n extension used for replication. This includes\n [changes to\n `enum` types](https://www.postgresql.org/docs/current/sql-altertype.html).\n\n - For example, `pglogical` provides a function\n `pglogical.replicate_ddl_command` that allows DDL to be run on\n both the source database and replica at a consistent point. The user\n running this command on the source must already exist on the replica.\n\n - In order to replicate data for new tables, you must use the\n `pglogical.replication_set_add_table` command to add\n the new tables to existing replication sets.\n\n - To learn more about DDL replication while the migration is in\n progress, see the section on\n [migration fidelity](/database-migration/docs/postgresql-to-alloydb/migration-fidelity).\n\n- For tables that don't have primary keys, Database Migration Service supports migration of the **initial snapshot and `INSERT` statements during the change data capture (CDC) phase** . You should migrate `UPDATE` and `DELETE` statements manually.\n\n- Database Migration Service doesn't migrate data from materialized views, just the view schema. To populate the views, run the following command: `REFRESH MATERIALIZED VIEW `\u003cvar translate=\"no\"\u003eview_name\u003c/var\u003e.\n\n- The `SEQUENCE` states (for example, `last_value`) on the new AlloyDB destination might vary from the source `SEQUENCE` states.\n\n- `UNLOGGED` and `TEMPORARY` tables aren't and can't be\n replicated.\n\n- Large Object data type isn't supported. More details in the section on\n [migration fidelity](/database-migration/docs/postgresql-to-alloydb/migration-fidelity).\n\n\u003c!-- --\u003e\n\n- Only [extensions and procedural languages](/alloydb/docs/reference/extensions) that AlloyDB supports for PostgreSQL can be migrated.\n\n\u003c!-- --\u003e\n\n- Database Migration Service doesn't support migrating from read replicas that are in recovery mode.\n\n- Database Migration Service doesn't support Amazon RDS sources where the AWS SCT extension pack is applied.\n\n\u003c!-- --\u003e\n\n- User-defined functions written in C can't be migrated, except for functions that are installed in the PostgreSQL database when you're installing [extensions](/alloydb/docs/reference/extensions) that are supported by AlloyDB.\n\n\u003c!-- --\u003e\n\n- If other extensions and procedural languages exist in the source database, or if their versions aren't supported, then when you test or start the migration job, it will fail.\n\n- Databases that are added after the migration job has started aren't migrated.\n\n\u003c!-- --\u003e\n\n- You can't select specific tables or schemas when you migrate by using Database Migration Service. Database Migration Service migrates all tables and schemas, except for the following:\n - The information schema (`information_schema`).\n - Any tables that begin with `pg`, for example, `pg_catalog`. For the full list of PostgreSQL catalogs that begin with `pg`, see [PostgreSQL system catalogs](https://www.postgresql.org/docs/current/catalogs.html) in the PostgreSQL documentation.\n - Information about users and user roles isn't migrated.\n\n\u003c!-- --\u003e\n\n- If encrypted databases require customer-managed encryption keys to decrypt the databases, and if Database Migration Service doesn't have access to the keys, then the databases can't be migrated.\n\n However, if customer data is encrypted by the [`pgcrypto` extension](/sql/docs/postgres/extensions#miscellaneous-extensions), then the data can be migrated with Database Migration Service (because AlloyDB supports the extension).\n\n Database Migration Service also supports migrating data from encrypted Amazon Aurora or Amazon RDS databases because these databases handle decryption transparently in their services. For more information, see [Encrypting Amazon Aurora resources](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.Encryption.html) and [Encrypting Amazon RDS resources](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html).\n- The destination AlloyDB database is\n writable during the migration\n to allow DDL changes to be applied if needed. Take care not to make any\n changes to the database configuration or table structures which might break\n the migration process or impact data integrity.\n\n- Trigger behavior depends on how they were configured. The default behavior is they\n won't trigger, but if they were configured using the\n `ALTER EVENT TRIGGER` or `ALTER TABLE` statement and the trigger state is set to either replica or always, then they will trigger\n on the replica during replication.\n\n- Functions with security definer will be created by\n `alloydbexternalsync` in AlloyDB primary. When it's\n executed by any users, it will be executed with the privileges of\n `alloydbexternalsync` which has `alloydbsuperuser` and\n `alloydbreplica` roles. It's better to restrict use of a security\n definer function to only some users. To do that, the user should revoke the\n default PUBLIC privileges and then grant execute privilege selectively.\n\n- [Private Service Connect interfaces connectivity method](/database-migration/docs/postgresql-to-alloydb/networking-methods#psc-interfaces)\n is only supported for migrating to existing destination instances.\n If you want to use private IP connectivity and migrate to a new destination\n instance, use VPC peering.\n\n### Limitations for migrations to existing destination clusters\n\n- Your existing destination cluster must be empty or contain only system configuration data. Migrating to existing destination cluster that contain user data (such as tables) isn't supported.\n- You can configure only one migration job per destination cluster.\n- Migrating to clusters with secondary clusters isn't supported.\n- Migrating to clusters with read pool instances **is supported** .\n\n For more information on AlloyDB for PostgreSQL clusters and instances, see\n [AlloyDB for PostgreSQL overview](/alloydb/docs/overview).\n\n### Quotas\n\n- Up to 2,000 connection profiles and 1,000 migration jobs can exist at any given time. To create space for more, migration jobs (including completed ones) and connection profiles can be deleted."]]
