Antes de migrar seus bancos de dados para o Cloud SQL, considere as limitações conhecidas desse cenário de migração.
Limitações conhecidas para o uso de um banco de dados PostgreSQL como fonte:
A extensão pglogical não é compatível com a replicação de colunas geradas para PostgreSQL 12 ou versões mais recentes.
As mudanças nas estruturas de tabela (DDL) não são replicadas com comandos DDL padrão, mas apenas com comandos executados usando a extensão pglogical usada para replicação. Isso inclui
mudanças nos
tipos enum.
Por exemplo, pglogical fornece uma função
pglogical.replicate_ddl_command que permite que a DDL seja executada no
banco de dados de origem e na réplica em um ponto consistente. O usuário que executa esse comando na origem já precisa existir na réplica.
Para replicar dados de novas tabelas, use o comando
pglogical.replication_set_add_table para adicionar
as novas tabelas aos conjuntos de replicação atuais.
Para saber mais sobre a replicação de DDL enquanto a migração está em
andamento, consulte a seção sobre
fidelidade da migração.
Para tabelas sem chaves primárias, o Database Migration Service oferece suporte à migração do snapshot inicial e das instruções INSERT durante a fase de captura de dados alterados (CDC). Migre as instruções UPDATE e DELETE manualmente.
O Database Migration Service não migra dados de visualizações materializadas, apenas o esquema da visualização. Para preencher as visualizações, execute o seguinte comando: REFRESH MATERIALIZED VIEW view_name.
Os estados SEQUENCE (por exemplo, last_value) no novo destino do Cloud SQL podem variar dos estados SEQUENCE de origem.
As tabelas UNLOGGED e TEMPORARY não são e não podem ser replicadas.
O tipo de dados Large Object não é compatível. Mais detalhes na seção sobre
fidelidade da migração.
Somente extensões e linguagens procedurais
compatíveis com o Cloud SQL para PostgreSQL podem ser migradas.
O Database Migration Service não migra extensões sem suporte do
Cloud SQL. A presença dessas extensões não bloqueia a migração, mas para garantir um processo tranquilo, verifique se seus objetos ou aplicativos não fazem referência a extensões sem suporte. Recomendamos remover
essas extensões e referências do banco de dados de origem antes de
continuar.
A extensão pg_cron (ou qualquer configuração cron associada a ela) não é migrada pelo Database Migration Service, mas é compatível com destinos do Cloud SQL para PostgreSQL. Se você usa a extensão pg_cron nos bancos de dados de origem, é possível reinstalá-la na instância de destino após a conclusão da migração.
O Database Migration Service não é compatível com a migração de réplicas de leitura em modo de recuperação.
O Database Migration Service não é compatível com origens do Amazon RDS em que o pacote de extensão do AWS SCT é aplicado.
As funções definidas pelo usuário escritas em C não podem ser migradas, exceto as funções instaladas no banco de dados PostgreSQL ao instalar extensões compatíveis com o Cloud SQL.
Se houver outras extensões e linguagens procedimentais no banco de dados de origem ou se as versões delas não forem compatíveis, o teste ou o job de migração vai falhar.
Os bancos de dados adicionados depois que o job de migração é iniciado não são migrados.
Não é possível selecionar tabelas ou esquemas específicos ao migrar usando o Database Migration Service.
O Database Migration Service migra todas as tabelas e esquemas, exceto os seguintes:
O esquema de informações (information_schema).
Qualquer tabela que comece com pg, por exemplo, pg_catalog. Para conferir a lista completa de catálogos do PostgreSQL que começam com pg, consulte Catálogos do sistema PostgreSQL na documentação do PostgreSQL.
As informações sobre usuários e funções não são migradas.
Se os bancos de dados criptografados exigirem chaves de criptografia gerenciadas pelo cliente para descriptografar os bancos de dados e se o Database Migration Service não tiver acesso às chaves, os bancos de dados não poderão ser migrados.
No entanto, se os dados do cliente forem criptografados pela extensão pgcrypto, eles poderão ser migrados com o Database Migration Service, já que o Cloud SQL é compatível com a extensão.
O Database Migration Service também oferece suporte à migração de dados de bancos de dados criptografados do Amazon Aurora ou do Amazon RDS, porque eles processam a descriptografia de maneira transparente nos serviços. Para mais informações, consulte Criptografar recursos do Amazon Aurora e Criptografar recursos do Amazon RDS.
O banco de dados de destino do Cloud SQL pode ser gravado durante a migração para permitir que as mudanças de DDL sejam aplicadas, se necessário. Tenha cuidado para não fazer mudanças na configuração do banco de dados ou nas estruturas de tabela que possam interromper o processo de migração ou afetar a integridade dos dados.
O comportamento do gatilho depende de como ele foi configurado. O comportamento padrão é que eles não sejam acionados, mas, se forem configurados usando a instrução ALTER EVENT TRIGGER ou ALTER TABLE e o estado de acionamento for definido como "replica" ou "always", eles serão acionados na réplica durante a replicação.
As funções com definidor de segurança serão criadas por
cloudsqlexternalsync na réplica do Cloud SQL. Quando executado por qualquer usuário, ele é executado com os privilégios de cloudsqlexternalsync, que tem as funções cloudsqlsuperuser e cloudsqlreplica. É melhor restringir o uso de uma função de
definição de segurança a apenas alguns usuários. Para isso, o usuário precisa revogar os
privilégios PUBLIC padrão e conceder o privilégio de execução seletivamente.
O Cloud SQL não é compatível com espaços de tabela personalizados. Todos os dados dentro de espaços de tabela personalizados são migrados para o espaço de tabela pg_default na instância de destino do Cloud SQL.
Limitações para migrações para instâncias de destino atuais
A instância de destino precisa estar vazia ou conter apenas dados de configuração do sistema. Não é possível migrar para instâncias de destino que já existem e contêm dados do usuário (como tabelas).
Se você encontrar problemas devido a dados extras na instância de destino atual, limpe os bancos de dados na instância de destino e tente novamente o job de migração.
Consulte Limpar dados extras da instância de destino atual.
Só é possível configurar um job de migração por instância de destino.
Caso sua instância tenha configurações de backup personalizadas, como um local de backup personalizado, personalize as configurações de backup novamente após promover a instância. Durante o processo de promoção, o Cloud SQL redefine suas configurações de backup para os valores padrão.
Para usuários do Terraform: o Database Migration Service modifica as configurações de backup
e recuperação da sua instância de destino. Isso pode fazer com que as configurações da instância de destino sejam diferentes da configuração do Terraform usada para provisionamento. Se você tiver esse problema,
siga as orientações em Diagnosticar problemas.
Cotas
É possível ter a qualquer momento até 2.000 perfis de conexão e 1.000 jobs de migração. Se você quiser criar mais espaço para esses itens, os jobs de migração (incluindo os concluídos)
e os perfis de conexão podem ser excluídos.
[[["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-09-05 UTC."],[[["\u003cp\u003eDatabase Migration Service for PostgreSQL has limitations regarding the replication of generated columns, DDL commands, and \u003ccode\u003eUPDATE\u003c/code\u003e and \u003ccode\u003eDELETE\u003c/code\u003e statements for tables without primary keys.\u003c/p\u003e\n"],["\u003cp\u003eCertain PostgreSQL features, such as \u003ccode\u003eUNLOGGED\u003c/code\u003e and \u003ccode\u003eTEMPORARY\u003c/code\u003e tables, large object data types, and unsupported extensions, are not supported by the Database Migration Service and cannot be migrated.\u003c/p\u003e\n"],["\u003cp\u003eDatabase Migration Service only migrates all tables and schemas in a database, and it does not migrate specific system schemas such as \u003ccode\u003einformation_schema\u003c/code\u003e and tables beginning with \u003ccode\u003epg\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eMigration to existing Cloud SQL instances is limited to instances that are empty or contain only system configuration data, and only one migration job is allowed per destination instance.\u003c/p\u003e\n"],["\u003cp\u003eThe destination Cloud SQL database is writable during the migration process, but users should avoid making changes to the database configuration or table structures that might affect data integrity.\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 \\| [PostgreSQL to AlloyDB](/database-migration/docs/postgresql-to-alloydb/known-limitations \"View this page for the PostgreSQL to AlloyDB version of Database Migration Service.\")\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nOverview\n--------\n\nBefore you choose to migrate your databases to\nCloud SQL, make sure you consider known limitations for this migration\nscenario.\n| **Note:** You can also use Google Cloud Migration Center to discover possible limitations or gaps in feature support for your specific scenario. See [Discover and import databases](/migration-center/docs/discover-and-import-databases) in the Migration Center documentation.\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/postgres/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 Cloud SQL 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/postgres/migration-fidelity).\n\n\u003c!-- --\u003e\n\n- Only [extensions and procedural languages](/sql/docs/postgres/extensions)\n that Cloud SQL supports for PostgreSQL can be migrated.\n Database Migration Service doesn't migrate extensions that are unsupported by\n Cloud SQL. The presence of these extensions doesn't block the migration,\n but to ensure a smooth migration process verify that your objects or\n applications don't reference any unsupported extensions. We recommend removing\n these extensions and references from your source database before you\n proceed.\n\n- The [`pg_cron`](/sql/docs/postgres/extensions#pg_cron)\n extension (or any `cron` settings associated with the extension)\n isn't migrated by Database Migration Service, but it is supported in\n Cloud SQL for PostgreSQL destinations. If you use the `pg_cron`\n extension in your source databases, you can re-install it on your destination\n instance after the migration is complete.\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](/sql/docs/postgres/extensions) that are supported by Cloud SQL.\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 Cloud SQL 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 Cloud SQL 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 `cloudsqlexternalsync` in Cloud SQL replica. When it's\n executed by any users, it will be executed with the privileges of\n `cloudsqlexternalsync` which has `cloudsqlsuperuser` and\n `cloudsqlreplica` 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- Cloud SQL does not support customized tablespaces. All the data inside customized\n tablespaces is migrated to the `pg_default` tablespace in the\n Cloud SQL destination instance.\n\n- [Private Service Connect interfaces connectivity method](/database-migration/docs/postgres/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\n ### Limitations for migrations to existing destination instances\n\n - Your existing destination instance must be empty or contain only system configuration data. Migrating to existing destination instances that contain user data (such as tables) isn't supported. If you encounter issues due to extra data in your existing destination\n instance, clear the databases in your destination instance and re-try the migration job.\n See [Clear extra\n data from your existing destination instance](/database-migration/docs/postgres/diagnose-issues#clear-ext-instance-data-steps).\n\n - You can configure only one migration job per destination instance.\n - You can only migrate to standalone Cloud SQL instances. Migrating to [external server replicas](/sql/docs/postgres/replication/configure-external-replica) isn't supported.\n - Migrating data to a Cloud SQL instance that has [Private Service Connect](/sql/docs/postgres/about-private-service-connect) enabled isn't supported.\n - After you promote an instance, you must turn on [point-in-time recovery](/sql/docs/postgres/backup-recovery/restore#tips-pitr).\n - If your instance has customized backup settings (for example, a [custom backup location](/sql/docs/postgres/backup-recovery/backing-up#locationbackups)), then after you promote the instance, you must customize your backup settings again. During the promotion process, Cloud SQL resets your backup settings to their default values.\n - **For Terraform users** : Database Migration Service modifies the backup and recovery settings of your destination instance. This might cause the destination instance settings to be different from the Terraform configuration you used for provisioning. If you experience this issue, follow the guidance in [Diagnose issues](/database-migration/docs/postgres/diagnose-issues#existing-instance-terraform-config-drift).\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."]]