About data flow for SQL Server to AlloyDB for PostgreSQL
Stay organized with collections
Save and categorize content based on your preferences.
There are two important concepts you need to understand to know how data flows
from your source to the destination cluster: migration types and migration
phases. Database Migration Service supports two types of migration: continuous and one-time.
Only continuous migrations are available for heterogeneous SQL Server
to Cloud SQL for PostgreSQL migrations.
With continuous migrations, your data is migrated in two phases: full dump, and
Change Data Capture (CDC).
Full dump phase
The full dump phase is the first part of the migration process. During
full dump, Database Migration Service connects to your source instance, reads the content
of the tables you selected for migration, and then loads the data to the
destination instance. In this phase, Database Migration Service captures actual contents
of your database.
The full dump phase depends on your source database snapshot consistency.
To ensure snapshot consistency, Database Migration Service requires that you
enable snapshot isolation when you
configure your source database for migration.
Enabling snapshot isolation creates a temporary view of your database at the start
of the full dump process. This ensures that the data being copied remains consistent,
even if other users are making changes to the live tables at the same time.
Enabling snapshot isolation might have a slight performance impact, but it's
essential for reliable data extraction.
Change Data Capture (CDC)
When the full dump phase is over, Database Migration Service switches to the
CDC phase where it keeps monitoring your source database for changes, and then
continuously replicates them on the destination cluster.
In this phase,
Database Migration Service doesn't copy actual data from your source database: instead,
it uses the
SQL Server change data capture mechanism to read
information from dedicated change tables. As DML events are applied to the
tables in your source database, the changes are recorded in the corresponding
change tables. These change tables have the same structure as
the source tables, but with extra columns to include the metadata for the changes.
Only committed transactions are added to the change tables, along with the log
sequence number (LSN) of the commit operation.
Database Migration Service requires that you enable the change data capture
mechanism on your source database for the migration. When this feature is active,
your source database is subject to certain operational limitations. For example,
you can't rename columns in your schema, or you might need to adjust maximum
size limits for write operations that involve Large Objects (LOBs).
For more information about how the change data capture feature in SQL Server
can impact your source database, see
Known limitations.
What's next
To learn more about data and feature support for heterogeneous SQL Server
migrations with Database Migration Service, see
Scenario overview.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-29 UTC."],[[["\u003cp\u003eDatabase Migration Service supports continuous migrations for heterogeneous SQL Server to Cloud SQL for PostgreSQL migrations, consisting of two phases: full dump and Change Data Capture (CDC).\u003c/p\u003e\n"],["\u003cp\u003eThe full dump phase involves copying the entire selected data from the source database to the destination, requiring snapshot isolation to ensure data consistency.\u003c/p\u003e\n"],["\u003cp\u003eThe Change Data Capture (CDC) phase tracks and replicates changes from the source to the destination using SQL Server's change data capture mechanism, recording DML events in change tables.\u003c/p\u003e\n"],["\u003cp\u003eEnabling snapshot isolation during the full dump phase and change data capture for CDC is necessary, with potential impacts on the source database's performance and operations.\u003c/p\u003e\n"],["\u003cp\u003eThis service is considered a Pre-GA offering, available "as is" with possibly limited support, and further information is available regarding data support, features and migration guides.\u003c/p\u003e\n"]]],[],null,["# About data flow for SQL Server to AlloyDB for PostgreSQL\n\nThere are two important concepts you need to understand to know how data flows\nfrom your source to the destination cluster: migration types and migration\nphases. Database Migration Service supports two types of migration: continuous and one-time.\nOnly continuous migrations are available for heterogeneous SQL Server\nto Cloud SQL for PostgreSQL migrations.\n\nWith continuous migrations, your data is migrated in two phases: full dump, and\nChange Data Capture (CDC).\n\nFull dump phase\n---------------\n\nThe **full dump phase** is the first part of the migration process. During\nfull dump, Database Migration Service connects to your source instance, reads the content\nof the tables you selected for migration, and then loads the data to the\ndestination instance. In this phase, Database Migration Service captures actual contents\nof your database.\n\nThe full dump phase depends on your source database snapshot consistency.\nTo ensure snapshot consistency, Database Migration Service requires that you\nenable snapshot isolation when you\n[configure your source database for migration](/database-migration/docs/sqlserver-to-csql-pgsql/configure-source-database).\nEnabling snapshot isolation creates a temporary view of your database at the start\nof the full dump process. This ensures that the data being copied remains consistent,\neven if other users are making changes to the live tables at the same time.\nEnabling snapshot isolation might have a slight performance impact, but it's\nessential for reliable data extraction.\n\nChange Data Capture (CDC)\n-------------------------\n\nWhen the **full dump** phase is over, Database Migration Service switches to the\nCDC phase where it keeps monitoring your source database for changes, and then\ncontinuously replicates them on the destination cluster.\n\nIn this phase,\nDatabase Migration Service doesn't copy actual data from your source database: instead,\nit uses the\n[SQL Server change data capture mechanism](https://learn.microsoft.com/en-us/sql/relational-databases/track-changes/about-change-data-capture-sql-server) to read\ninformation from dedicated *change tables*. As DML events are applied to the\ntables in your source database, the changes are recorded in the corresponding\nchange tables. These change tables have the same structure as\nthe source tables, but with extra columns to include the metadata for the changes.\nOnly committed transactions are added to the change tables, along with the log\nsequence number (LSN) of the commit operation.\n\nDatabase Migration Service requires that you enable the change data capture\nmechanism on your source database for the migration. When this feature is active,\nyour source database is subject to certain operational limitations. For example,\nyou can't rename columns in your schema, or you might need to adjust maximum\nsize limits for write operations that involve Large Objects (LOBs).\nFor more information about how the change data capture feature in SQL Server\ncan impact your source database, see\n[Known limitations](/database-migration/docs/sqlserver-to-csql-pgsql/known-limitations#cdc-considerations).\n\nWhat's next\n-----------\n\n- To learn more about data and feature support for heterogeneous SQL Server\n migrations with Database Migration Service, see\n [Scenario overview](/database-migration/docs/sqlserver-to-csql-pgsql/scenario-overview).\n\n- To get a complete, step-by-step migration walkthrough, see\n [SQL Server to Cloud SQL for PostgreSQL migration guide](/database-migration/docs/sqlserver-to-csql-pgsql/guide)."]]