Bevor Sie Ihre Datenbanken zu Cloud SQL migrieren, sollten Sie die bekannten Einschränkungen für dieses Migrationsszenario berücksichtigen.
Bekannte Einschränkungen bei Verwendung einer PostgreSQL-Datenbank als Quelle:
Die pglogical-Erweiterung unterstützt die Replikation von generierten Spalten für PostgreSQL 12 und höher nicht.
Änderungen an Tabellenstrukturen (DDL) werden nicht über Standard-DDL-Befehle repliziert, sondern nur über Befehle, die mit der für die Replikation verwendeten pglogical-Erweiterung ausgeführt werden. Dazu gehören Änderungen an enum-Typen.
pglogical bietet beispielsweise eine Funktion pglogical.replicate_ddl_command, mit der DDL an einem konsistenten Punkt sowohl in der Quelldatenbank als auch im Replikat ausgeführt werden kann. Der Nutzer, der diesen Befehl für die Quelle ausführt, muss bereits auf dem Replikat vorhanden sein.
Wenn Sie Daten für neue Tabellen replizieren möchten, müssen Sie die neuen Tabellen mit dem Befehl pglogical.replication_set_add_table zu vorhandenen Replikationssets hinzufügen.
Weitere Informationen zur DDL-Replikation während der Migration finden Sie im Abschnitt zur Migrationstreue.
Bei Tabellen ohne Primärschlüssel unterstützt Database Migration Service die Migration des ersten Snapshots und der INSERT-Anweisungen während der CDC-Phase (Change Data Capture). Sie sollten die Anweisungen UPDATE und DELETE manuell migrieren.
Der Database Migration Service migriert keine Daten aus materialisierten Ansichten, sondern nur das Ansichtsschema. Führen Sie den folgenden Befehl aus, um die Ansichten zu füllen: REFRESH MATERIALIZED VIEW view_name.
Die SEQUENCE-Status (z. B. last_value) in der neuen Cloud SQL-Zielinstanz können sich von den SEQUENCE-Status der Quelle unterscheiden.
UNLOGGED- und TEMPORARY-Tabellen werden nicht repliziert und können auch nicht repliziert werden.
Der Datentyp „Large Object“ wird nicht unterstützt. Weitere Informationen finden Sie im Abschnitt zur Migrationsgenauigkeit.
Es können nur Erweiterungen und prozedurale Sprachen migriert werden, die von Cloud SQL für PostgreSQL unterstützt werden.
Database Migration Service migriert keine Erweiterungen, die von Cloud SQL nicht unterstützt werden. Das Vorhandensein dieser Erweiterungen blockiert die Migration nicht. Um jedoch einen reibungslosen Migrationsprozess zu gewährleisten, sollten Sie prüfen, ob Ihre Objekte oder Anwendungen auf nicht unterstützte Erweiterungen verweisen. Wir empfehlen, diese Erweiterungen und Verweise aus Ihrer Quelldatenbank zu entfernen, bevor Sie fortfahren.
Die Erweiterung pg_cron (oder alle cron-Einstellungen, die mit der Erweiterung verknüpft sind) wird nicht von Database Migration Service migriert, wird aber in Cloud SQL for PostgreSQL-Zielen unterstützt. Wenn Sie die pg_cron-Erweiterung in Ihren Quelldatenbanken verwenden, können Sie sie nach Abschluss der Migration auf Ihrer Zielinstanz neu installieren.
Der Database Migration Service unterstützt keine Migration von Lesereplikaten, die sich im Wiederherstellungsmodus befinden.
Database Migration Service unterstützt keine Amazon RDS-Quellen, auf die das AWS SCT-Erweiterungspaket angewendet wird.
In C geschriebene benutzerdefinierte Funktionen können nicht migriert werden, mit Ausnahme von Funktionen, die in der PostgreSQL-Datenbank installiert werden, wenn Sie von Cloud SQL unterstützte Erweiterungen installieren.
Wenn in der Quelldatenbank andere Erweiterungen und prozedurale Sprachen vorhanden sind oder ihre Versionen nicht unterstützt werden, schlägt der Test oder der Start des Migrationsjobs fehl.
Datenbanken, die nach dem Start des Migrationsjobs hinzugefügt werden, werden nicht migriert.
Wenn Sie Database Migration Service für die Migration verwenden, können Sie keine bestimmten Tabellen oder Schemas auswählen.
Der Database Migration Service migriert alle Tabellen und Schemas mit Ausnahme der folgenden:
Das Informationsschema (information_schema).
Alle Tabellen, die mit pg beginnen, z. B. pg_catalog. Die vollständige Liste der PostgreSQL-Kataloge, die mit pg beginnen, finden Sie in der PostgreSQL-Dokumentation unter PostgreSQL-Systemkataloge.
Informationen zu Nutzern und Nutzerrollen werden nicht migriert.
Wenn für verschlüsselte Datenbanken vom Kunden verwaltete Verschlüsselungsschlüssel zum Entschlüsseln der Datenbanken erforderlich sind und Database Migration Service keinen Zugriff auf die Schlüssel hat, können die Datenbanken nicht migriert werden.
Wenn Kundendaten jedoch von der pgcrypto-Erweiterung verschlüsselt werden, können die Daten mit dem Database Migration Service migriert werden, da Cloud SQL die Erweiterung unterstützt.
Database Migration Service unterstützt auch die Migration von Daten aus verschlüsselten Amazon Aurora- oder Amazon RDS-Datenbanken, da diese Datenbanken die Entschlüsselung transparent in ihren Diensten verarbeiten. Weitere Informationen finden Sie unter Amazon Aurora-Ressourcen verschlüsseln und Amazon RDS-Ressourcen verschlüsseln.
Die Cloud SQL-Zieldatenbank ist während der Migration beschreibbar, damit bei Bedarf DDL-Änderungen angewendet werden können. Nehmen Sie keine Änderungen an der Datenbankkonfiguration oder den Tabellenstrukturen vor, die den Migrationsprozess unterbrechen oder die Datenintegrität beeinträchtigen könnten.
Das Triggerverhalten hängt davon ab, wie sie konfiguriert wurden. Standardmäßig werden sie nicht ausgelöst. Wenn sie jedoch mit der Anweisung ALTER EVENT TRIGGER oder ALTER TABLE konfiguriert wurden und der Triggerstatus auf „replica“ oder „always“ festgelegt ist, werden sie während der Replikation auf der Replik ausgelöst.
Funktionen mit dem Sicherheitsdefinierer werden von cloudsqlexternalsync im Cloud SQL-Replikat erstellt. Wenn der Befehl von einem beliebigen Nutzer ausgeführt wird, erfolgt die Ausführung mit den Berechtigungen von cloudsqlexternalsync, der die Rollen cloudsqlsuperuser und cloudsqlreplica hat. Es ist besser, die Verwendung einer Sicherheitsdefiniererfunktion auf einige Nutzer zu beschränken. Dazu sollte der Nutzer die standardmäßigen PUBLIC-Berechtigungen widerrufen und dann die Ausführungsberechtigung selektiv erteilen.
Cloud SQL unterstützt keine benutzerdefinierten Tablespaces. Alle Daten in benutzerdefinierten Tablespaces werden zum Tablespace pg_default in der Cloud SQL-Zielinstanz migriert.
Einschränkungen für die Migration zu vorhandenen Zielinstanzen
Die vorhandene Zielinstanz muss leer sein oder darf nur Daten zur Systemkonfiguration enthalten. Die Migration zu vorhandenen Zielinstanzen, die Nutzerdaten (z. B. Tabellen) enthalten, wird nicht unterstützt.
Wenn Probleme aufgrund zusätzlicher Daten in der vorhandenen Zielinstanz auftreten, löschen Sie die Datenbanken in der Zielinstanz und versuchen Sie es noch einmal mit dem Migrationsjob.
Weitere Informationen finden Sie unter Zusätzliche Daten aus Ihrer vorhandenen Zielinstanz löschen.
Sie können nur einen Migrationsjob pro Zielinstanz konfigurieren.
Sie können nur zu eigenständigen Cloud SQL-Instanzen migrieren. Die Migration zu externen Serverreplikaten wird nicht unterstützt.
Die Migration von Daten zu einer Cloud SQL-Instanz, für die
Private Service Connect aktiviert ist, wird nicht unterstützt.
Wenn Ihre Instanz benutzerdefinierte Sicherungseinstellungen hat (z. B. einen benutzerdefinierten Sicherungsspeicherort), müssen Sie die Sicherungseinstellungen nach dem Hochstufen der Instanz noch einmal anpassen. Während des Hochstufungsprozesses setzt Cloud SQL Ihre Sicherungseinstellungen auf die Standardwerte zurück.
Für Terraform-Nutzer: Der Database Migration Service ändert die Sicherungs- und Wiederherstellungseinstellungen Ihrer Zielinstanz. Dies kann dazu führen, dass die Einstellungen der Zielinstanz von der Terraform-Konfiguration abweichen, die Sie für die Bereitstellung verwendet haben. Wenn dieses Problem auftritt, folgen Sie der Anleitung unter Fehlerdiagnose.
Kontingente
Es können immer bis zu 2.000 Verbindungsprofile und 1.000 Migrationsjobs gleichzeitig vorhanden sein. Wenn Platz für weitere Jobs und Profile benötigt wird, können Migrationsjobs (einschließlich bereits abgeschlossene) und Verbindungsprofile gelöscht werden.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-22 (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."]]
