Antes de migrar tus bases de datos a Cloud SQL, asegúrate de tener en cuenta las limitaciones conocidas para este caso de migración.
Entre las limitaciones conocidas para usar una base de datos de PostgreSQL como fuente, se incluyen las siguientes:
La extensión pglogical no admite la replicación de columnas generadas para PostgreSQL 12 y versiones posteriores.
Los cambios en las estructuras de las tablas (DDL) no se replican a través de los comandos DDL estándar, sino solo con los comandos ejecutados con la extensión pglogical que se usa para la replicación. Esto incluye cambios en los tipos de enum.
Por ejemplo, pglogical proporciona una función pglogical.replicate_ddl_command que permite que el DDL se ejecute en la base de datos de origen y en la réplica en un punto coherente. El usuario que ejecuta este comando en la fuente ya debe existir en la réplica.
Para replicar datos en tablas nuevas, debes usar el comando pglogical.replication_set_add_table para agregar las tablas nuevas a los conjuntos de replicación existentes.
Para obtener más información sobre la replicación de DDL mientras la migración está en curso, consulta la sección sobre la fidelidad de la migración.
Para las tablas que no tienen claves primarias, Database Migration Service admite la migración de la instantánea inicial y las sentencias INSERT durante la fase de captura de datos modificados (CDC). Debes migrar las declaraciones UPDATE y DELETE de forma manual.
Database Migration Service no migra datos de vistas materializadas, solo el esquema de la vista. Para completar las vistas, ejecuta el siguiente comando: REFRESH MATERIALIZED VIEW view_name.
Los estados SEQUENCE (por ejemplo, last_value) en el nuevo destino de Cloud SQL pueden variar de los estados SEQUENCE de la fuente.
Las tablas UNLOGGED y TEMPORARY no se replican ni se pueden replicar.
No se admite el tipo de datos Large Object. Encontrarás más detalles en la sección sobre la fidelidad de la migración.
Solo se pueden migrar las extensiones y los lenguajes de procedimientos que Cloud SQL admite para PostgreSQL.
Database Migration Service no migra las extensiones que no son compatibles con Cloud SQL. La presencia de estas extensiones no bloquea la migración, pero, para garantizar un proceso sin problemas, verifica que tus objetos o aplicaciones no hagan referencia a extensiones no admitidas. Te recomendamos que quites estas extensiones y referencias de tu base de datos de origen antes de continuar.
Database Migration Service no migra la extensión pg_cron (ni ningún parámetro de configuración de cron asociado con la extensión), pero es compatible con los destinos de Cloud SQL para PostgreSQL. Si usas la extensión pg_cron en tus bases de datos de origen, puedes volver a instalarla en tu instancia de destino después de que se complete la migración.
Database Migration Service no admite la migración desde réplicas de lectura que se encuentran en modo de recuperación.
Database Migration Service no admite fuentes de Amazon RDS en las que se aplica el paquete de extensión de AWS SCT.
Las funciones definidas por el usuario escritas en C no se pueden migrar, excepto las funciones que se instalan en la base de datos de PostgreSQL cuando instalas extensiones compatibles con Cloud SQL.
Si existen otras extensiones y lenguajes procedurales en la base de datos de origen, o si sus versiones no son compatibles, cuando pruebes o inicies el trabajo de migración, este fallará.
No se migran las bases de datos que se agregan después de que se inicia el trabajo de migración.
No puedes seleccionar tablas o esquemas específicos cuando migras con Database Migration Service.
Database Migration Service migra todas las tablas y los esquemas, excepto los siguientes:
Esquema de información (information_schema).
Cualquier tabla que comience con pg, por ejemplo, pg_catalog. Para obtener la lista completa de los catálogos de PostgreSQL que comienzan con pg, consulta Catálogos del sistema de PostgreSQL en la documentación de PostgreSQL.
No se migra la información sobre los usuarios ni los roles de los usuarios.
Si las bases de datos encriptadas requieren claves de encriptación administradas por el cliente para desencriptarlas y si Database Migration Service no tiene acceso a las claves, no se podrán migrar las bases de datos.
Sin embargo, si los datos del cliente están encriptados con la extensión pgcrypto, se pueden migrar con Database Migration Service (porque Cloud SQL admite la extensión).
Database Migration Service también admite la migración de datos desde bases de datos encriptadas de Amazon Aurora o Amazon RDS, ya que estas bases de datos controlan el desencriptado de forma transparente en sus servicios. Para obtener más información, consulta Cómo encriptar recursos de Amazon Aurora y Cómo encriptar recursos de Amazon RDS.
La base de datos de destino de Cloud SQL se puede escribir durante la migración para permitir que se apliquen cambios en el DDL si es necesario. Ten cuidado de no realizar ningún cambio en la configuración de la base de datos ni en las estructuras de las tablas que puedan interrumpir el proceso de migración o afectar la integridad de los datos.
El comportamiento de los activadores depende de cómo se configuraron. El comportamiento predeterminado es que no se activarán, pero si se configuraron con la instrucción ALTER EVENT TRIGGER o ALTER TABLE y el estado del activador se establece en réplica o siempre, se activarán en la réplica durante la replicación.
cloudsqlexternalsync creará funciones con definidor de seguridad en la réplica de Cloud SQL. Cuando la ejecuten los usuarios, se ejecutará con los privilegios de cloudsqlexternalsync, que tiene los roles cloudsqlsuperuser y cloudsqlreplica. Es mejor restringir el uso de una función de definidor de seguridad solo a algunos usuarios. Para ello, el usuario debe revocar los privilegios PUBLIC predeterminados y, luego, otorgar el privilegio de ejecución de forma selectiva.
Cloud SQL no admite espacios de tabla personalizados. Todos los datos dentro de los espacios de tabla personalizados se migran al espacio de tabla pg_default en la instancia de destino de Cloud SQL.
Limitaciones para las migraciones a instancias de destino existentes
Tu instancia de destino existente debe estar vacía o contener solo datos de configuración del sistema. No se admite la migración a instancias de destino existentes que contengan datos del usuario (como tablas).
Si tienes problemas debido a datos adicionales en tu instancia de destino existente, borra las bases de datos de tu instancia de destino y vuelve a intentar el trabajo de migración.
Consulta Borra los datos adicionales de tu instancia de destino existente.
Solo puedes configurar un trabajo de migración por instancia de destino.
Si tu instancia tiene una configuración de copia de seguridad personalizada (por ejemplo, una ubicación de copia de seguridad personalizada), debes volver a personalizar la configuración de tu copia de seguridad después de ascender la instancia. Durante el proceso de promoción, Cloud SQL restablece la configuración de tu copia de seguridad a los valores predeterminados.
Para los usuarios de Terraform: Database Migration Service modifica la configuración de copia de seguridad y recuperación de tu instancia de destino. Esto podría hacer que la configuración de la instancia de destino sea diferente de la configuración de Terraform que usaste para el aprovisionamiento. Si tienes este problema, sigue las instrucciones en Diagnostica problemas.
Cuotas
Pueden existir hasta 2,000 perfiles de conexión y 1,000 trabajos de migración en un momento determinado. Para liberar espacio, se pueden borrar trabajos de migración (incluso los que están completos) y perfiles de conexión.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]