Which Schema Changes Can Cross an AWS DMS CDC Migration?

Classify PostgreSQL schema changes during task-based AWS DMS CDC as controlled replication, separate schema work or deferred release work, with an inspectable release...

During a task-based AWS DMS migration, approve schema changes individually. A source statement needs a documented capture path, a supported target-apply path and a compatible application release. A setting that enables ALTER handling cannot supply any missing part of that evidence. Freeze unreviewed changes; put deliberately separate target schema work under its own owner and sequence.

The useful artifact is a change register linking each exact statement to its source table, DMS task, target representation, application builds and expected observations. It lets a migration owner explain why an additive column might proceed through a controlled replication rehearsal while a default change needs separate schema preparation and a key redesign waits for another migration plan.

This article uses a proposed RDS for PostgreSQL 15.x writer-instance source and RDS for PostgreSQL 15.x instance target, with an AWS DMS replication-instance task in its CDC phase after full load. The planning engine is DMS 3.6.1. Exact deployed PostgreSQL minor versions, DMS readback, Regions and endpoint settings are UNKNOWN because no deployment exists for this example. PostgreSQL 15 is listed for both endpoints, with the documented DMS 3.5.3-and-later support boundary. Verify the actual combination before applying the review. DMS sources, DMS targets

Aurora, read-replica sources, Babelfish, partitioned tables, heterogeneous engine pairs, DMS Serverless, homogeneous data migrations and DMS Schema Conversion are excluded. The source remains the only application writer until a separately accepted cutover. Every identifier, release and observation below is fictional. No SQL, DMS task or AWS operation was executed.

Read the three DDL boundaries separately

AWS's general supported-DDL list includes adding a column, but explicitly defers to source and target endpoint restrictions. It also warns about rapid DDL/DML/DDL sequences and instructs teams to wait for a change to be applied at the target before subsequent operations. That gives the reviewer a sequencing requirement, not a fixed safe sleep interval. DMS supported DDL

For the PostgreSQL source, AWS excludes default-setting changes, nullability changes and primary-key definition changes from supported change processing. It also excludes table DDL inside nested function or procedure bodies. In particular, changing the primary-key structure during active replication prevents subsequent changes to affected tables from being replicated. Review the exact operation rather than approving the entire ALTER TABLE family. PostgreSQL source limitations

Capture configuration is another boundary. CaptureDdls is a PostgreSQL endpoint property, documented as defaulting to true; DMS uses database artifacts for DDL capture. Retain effective configuration and the required artifact/permission evidence rather than assuming an omitted field proves a working capture path. PostgreSQL endpoint API

On the target-handling side, HandleSourceTableAltered, HandleSourceTableDropped and HandleSourceTableTruncated govern the corresponding CDC behavior. The documentation's all-true JSON is an example, not this task's observed configuration or a permission recommendation. Enabling a category does not extend endpoint support. DDL handling settings

The application has a fourth, separate responsibility: every build allowed to run must understand its database state. DMS documentation does not know whether an old worker requires the former field, whether a recovery build expects a default or whether a report interprets null as “unknown.” The migration register should name those consumers and their contracts without making replication status their compatibility oracle.

Choose a disposition before the release reaches production

Use three local planning dispositions. They are not AWS task states and none authorizes a production change.

Controlled replication candidate means the exact statement appears supported for the reviewed endpoint pair and configuration. An authorized rehearsal still needs to demonstrate target structure, subsequent data changes, application behavior and recovery. The reviewer has not approved every statement that shares the same SQL verb.

Separate schema work required means this change cannot rely on the reviewed DMS DDL path. A database owner must design the target change, its relationship to the source release, apply behavior, existing data and recovery. Identical SQL on both sides may be part of that design, but the decision record must prevent an automatic DMS path and a manual operator from both owning the same change accidentally. This article supplies no blanket target-first or source-first workaround.

Deferred or redesigned means the change closes an application or replication boundary that the current migration plan cannot preserve. Postponing it may keep the migration simpler. If the product release cannot wait, the team needs a different scoped plan and fresh evidence, rather than silently declaring the migration freeze optional.

Unknown evidence holds the release decision within any disposition. An unreadable endpoint configuration cannot be treated as its default. A missing target observation cannot become a delayed success. Keep the proposed classification, observed facts and permitted next action in separate fields so reviewers can see the difference between an eligible rehearsal and an accepted production result.

Work one release through the register

Consider fictional release R42 for an ordinary orders table with an existing integer primary key order_id. The migration baseline contains order_id and a nullable shipping_class field. The target is used only for read-only migration checks. Old application R41 remains an allowed recovery build. Four proposed changes arrive together:

C1: Add customer reference: Add nullable customer_ref varchar(40) without a default. Proposed disposition: controlled replication candidate, conditional on exact support, capture and target-handling evidence. Both R41 and R42 must tolerate its initial absence of values; R42 must not start using it before the reviewed schema boundary.
C2: Change the shipping default: Set shipping_class default to the literal standard. Proposed disposition: separate schema work required. Record how the target acquires the required future-write behavior rather than assuming C1's successful replication covers C2.
C3: Require the new reference: Set customer_ref to NOT NULL. Proposed disposition: defer from this CDC release. The assumed old writer may omit the field, existing records need a declared treatment and the native DDL capture path does not close the target requirement.
C4: Replace the primary key: Replace order_id with a composite application key. Proposed disposition: redesign or defer outside the active task's present plan. Do not test this on the production source to see whether replication notices.

The proposed review therefore has four changes: one replication candidate, one separate-schema item and two deferred/redesigned items. Zero are approved for production in this article. Those counts are classifications of fictional inputs, not migration success percentages. Splitting R42 into smaller releases is useful only if the application owner confirms that each smaller release still meets its own business contract.

For C1, the database owner would first approve the exact isolated rehearsal and expected state. After the approved source addition, confirm the expected target column before introducing the next test operation, then observe that operation at the target before proceeding. Its observation should cover the new target column's type and nullability, a source insert that includes a reference, an update of that reference, and the corresponding target state at a defensible paired boundary. The application owner should exercise R41 and R42 query and result-decoding paths against the resulting schema. “A column appeared” is weaker than evidence that subsequent required operations still work.

Only after the accepted C1 boundary should the next independently authorized operation begin. If the target column is absent, differently mapped or unobserved, hold the release and preserve the source statement, task/configuration revisions and last conclusive observations. An arbitrary five-second delay cannot close an unknown target state. DMS's sequencing guidance is not a claim that all required application checks become automatic once the DDL appears.

For C2, the owner must decide whether the new default is needed on the target before it becomes a writer, how that state will be prepared and how the plan avoids conflicting apply paths. Keep that decision open until supported engine-specific rehearsal and resulting-schema evidence exist. Reviewing a proposed replay is not permission to execute it, and a status labelled complete must identify which side and which statement completed.

Matching rows can conceal a future-write defect

Use a counterexample to test what the release review is proving. Suppose two existing fictional rows have explicit shipping_class values, express and standard. Both source and target currently contain those same values. Next, the source's default is changed to standard, while the target retains no default. A row comparison of those two unchanged records still agrees.

Now stipulate that the future writer omits shipping_class when creating a new order. Under the source-side definition it gets standard; under the target-side nullable definition it gets null. This is an independently specified schema-state example, not an observed DMS output. PostgreSQL documents that changing a default affects future inserts rather than existing rows. Existing-row equality therefore cannot decide whether the future writer has the required default. PostgreSQL 15 table modifications

Even a later copied row with a stored standard value would not establish the target's own default. A data value and the rule the database uses when a future writer omits that value answer different questions. Keep the future-write probe explicit, including omitted fields, explicit nulls, accepted defaults and the resulting business interpretation. Do not change the comparator to replace target null with standard and call the database contract satisfied.

The same example exposes a recovery problem. If R42 starts depending on the new reference while R41 remains permitted to omit it, enforcing C3 can make the recovery build incompatible. The column-retirement article owns the broader consumer and rollback-build review. For this migration, also establish the DMS capture and target-apply path for each particular DDL statement.

Keep target preparation distinct from ongoing DDL

A separate target change needs an explicit survival boundary. AWS documents TargetTablePrepMode as a full-load startup setting: DO_NOTHING leaves existing data and metadata unaffected, DROP_AND_CREATE replaces the table, and TRUNCATE_BEFORE_LOAD removes data without changing metadata. These descriptions are not a promise that every restart or reload follows a particular preparation path. Review the exact proposed operation before relying on manually prepared schema. DMS full-load settings

In the example, a later plan that recreates the target table would invalidate an earlier observation of its separately prepared default. The register needs to say what would invalidate the accepted result and who must renew it. It should not imply that choosing DO_NOTHING repairs unsupported capture or proves the application can use the resulting table.

For the PostgreSQL target, AWS also states that ongoing replication does not migrate sequences. Sequence readiness is therefore a separate future-writer item if the workload uses them, even when copied identifiers agree. PostgreSQL target limitations The worked order_id values are explicit integers and do not model allocation. This boundary is named to prevent the DDL register from being misread as complete cutover acceptance.

If maintaining two live schema contracts is too costly, compare a bounded schema freeze with a separately authorized maintenance-window approach. A freeze needs an owner, start/end conditions and an exception route; otherwise an unattended release pipeline may violate it. A maintenance window needs its own interruption and recovery plan. An urgent security or regulatory release may justify changing the migration plan, but cannot make an undocumented DDL path supported.

Use one record per change, plus a release-level decision

The filled record below concerns only C2. It deliberately retains an unresolved result, because this article has no real target-schema evidence. Keep controlled evidence references rather than credentials, production rows or raw private migration plans in the review ticket.

Change and owner: C2, R42; database owner and application owner roles assigned in the fictional plan, no real approver identified.
Endpoint and task boundary: Proposed RDS PostgreSQL 15.x writer instance to RDS PostgreSQL 15.x instance; DMS3.6.1 replication-instance task, CDC after full load. Exact readbacks UNKNOWN.
Statement, object and expected effect: Set the orders.shipping_class default to standard. Required future writer may omit this field. Existing express/standard rows should remain unchanged.
Capture, handling and mapping evidence: Native change-processing limitation identified; actual CaptureDdls, DDL-handling policy, table mappings and target schema UNKNOWN. No setting overrides the support boundary.
Application and recovery contract: R41 remains an allowed recovery build; C1 stays nullable. R42 cannot depend on an unverified target default. Target application writes remain prohibited before cutover.
Expected controls and observation: Compare existing rows and inspect the default separately; isolated omitted-field future-write probe must distinguish standard from null. No probe executed.
Disposition, invalidation and next action: Separate schema work required; HOLD release acceptance pending an authorized sequencing/rehearsal design. Target recreation, changed statements, versions or application assumptions invalidate prior evidence. Database owner drafts that design for review.

Copy the following blank record for each proposed DDL operation. One register row should not hide several different statements inside a label such as “shipping migration.” Record the release-level decision after checking every row and their ordering dependencies.

Change and owner: Enter immutable change/release identifiers, accountable database and application owners, evidence time and controlled references.
Endpoint and task boundary: Enter exact source/target identities, engines and minors, deployment types, DMS engine, task phase and effective configuration revision. Mark missing readbacks UNKNOWN.
Statement, object and expected effect: Identify the exact statement revision, schema/table/column, current and required definitions, existing-data treatment and future-write behavior.
Capture, handling and mapping evidence: Link current endpoint-specific support, effective capture/artifact evidence, DDL-handling policy, selection/transformation rules and target application evidence. Assign every unknown.
Application and recovery contract: List permitted readers/writers and recovery artifacts, expected omitted/null/default behavior, write-authority boundary and last accepted recovery state.
Expected controls and observation: Specify the isolated authorized rehearsal, independently expected positive and failing cases, paired data boundary, resulting-schema readback and stop conditions.
Disposition, invalidation and next action: Choose controlled replication candidate, separate schema work or deferred/redesigned. Record observed acceptance separately, invalidating changes, missing artifact, responsible owner and permitted next step.

Stop on missing evidence, not only a failed task

An authorized rehearsal should include deliberately adverse cases: required capture evidence unavailable; alteration handling disabled; target column absent; an old writer omitting the proposed required value; matching existing rows with the wrong default; and a target recreation after separate preparation. The expected review outcome is HOLD for each unresolved required boundary. These are proposed tests, not a claim that DMS produces a particular error code or task state in every case.

If an observation is denied, record the scope and failure and ask its owner for the minimum approved evidence. Do not broaden privileges or modify the task as a diagnostic shortcut. If a client loses certainty about whether DDL completed, inspect actual schema state before proposing another application of the statement. A second execution is a state change, not an innocent readback.

When the source change has already occurred unexpectedly, preserve its identity, the prior configuration and the last conclusive target observations. Hold downstream release or cutover decisions whose prerequisites no longer apply. The accountable incident and database owners then select containment and a supported recovery or forward-repair plan. This article does not prescribe a task restart, reload, reverse DDL or automatic rollback; each can affect data and requires its own reviewed scope.

Keep business reconciliation and LOB comparison coverage as separate acceptance work. A complete DDL register cannot certify either. Bring one real proposed statement to the next migration review with its capture path, target effect and application dependency filled in. If one of those remains UNKNOWN, assign that evidence request before scheduling the release.

Related services

AWS Consulting Services for Architecture, Cost & Migration
AWS consulting for architecture and Well-Architected reviews, cost optimisation, FinOps and migration. Plan changes around workload evidence and recovery needs.