As limitações conhecidas para usar uma base de dados PostgreSQL como origem incluem:
- A extensão - pglogicalnã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 - pglogicalusada para replicação. Isto inclui alterações aos- enumtipos.- Por exemplo, - pglogicalfornece uma função- pglogical.replicate_ddl_commandque 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_tablepara 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 - INSERTdurante a fase de captura de dados de alterações (CDC). Deve migrar as declarações- UPDATEe- DELETEmanualmente.
- 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- SEQUENCEde origem.
- As tabelas - UNLOGGEDe- TEMPORARYnã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. 
- Só é possível migrar extensões e linguagens processuais que o AlloyDB suporta para o PostgreSQL.
- 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 porpg, 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.
 
- O esquema de informações (
- 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 TRIGGERou- ALTER TABLEe 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 - alloydbexternalsyncno AlloyDB primário. Quando é executado por qualquer utilizador, é executado com os privilégios de- alloydbexternalsync, que tem as funções- alloydbsuperusere- 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.
- O método de conetividade das interfaces do Private Service Connect só é suportado para a migração para instâncias de destino existentes. Se quiser usar a conetividade IP privada e migrar para uma nova instância de destino, use o peering de VPC. 
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.
  Para mais informações sobre clusters e instâncias do AlloyDB for PostgreSQL, consulte a vista geral do AlloyDB for PostgreSQL. 
Quotas
- 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.