AWS DMS for Ongoing Replication Limitations

For fan-in CDC replication from multiple operational databases into a single warehouse, AWS DMS is a defensible choice only when change volumes, schema stability, latency expectations, and manual operating costs fit its limits. This article explains AWS DMS’s ongoing replication limitations and their common origin in migration-era architecture. Supporting continuous change capture is not the same as guaranteeing that an indefinite production pipeline stays current, complete, and correct.

Why AWS DMS exists and what it was designed to do

AWS launched the Database Migration Service in 2016 to help businesses lift-and-shift database workloads as they began moving to the cloud. Its sources included Oracle, SQL Server, MySQL, PostgreSQL, and MariaDB, with destinations including AWS RDS, Aurora, and Amazon EC2. The purpose was bounded migration. Its architecture favored a full initial load followed by enough change data capture, or CDC, to keep the target synchronized during a finite migration window.

That distinction explains the mismatch teams encounter when they make DMS a permanent production dependency. AWS markets DMS as supporting ongoing replication, and teams reasonably adopt it for that purpose. But support for a task type does not establish the operating guarantees that every workload needs. The service’s name identifies its original job. Its throughput, recovery, and schema-handling limits all stem from that architecture.

How DMS's single-threaded apply loop creates compounding replication lag

DMS tasks are single-threaded by default and have limited internal parallelism, so the rate of a single apply loop bounds their throughput. Under high-change-rate workloads, with thousands of rows changing per minute, incoming changes can outpace that loop. The backlog then grows with each write burst. Without automatic scaling of the apply path, lag compounds rather than correcting itself while incoming work continues to exceed processing capacity.

AWS reported a test in which target CDC latency reached roughly 600 seconds when writes were heavy. Changes are applied row-by-row rather than transactionally, so related updates have no guarantee of atomicity across the apply process. Referential integrity between tables can therefore break when changes come in at a high rate.

Creating parallel tasks can improve throughput, but it transfers part of the problem to operations. Each task needs its own monitoring, error handling, and plan for rollback. The maintenance burden grows with the task count. A team using DMS to feed one warehouse from several production databases must account for that burden across the replication paths.

The replication instance also holds intermediate caches and buffers while changes await application. When the target slows, those buffers become another constraint. If they overflow, DMS may throttle, drop events, or halt entirely. Recovery can require task recreation. At that point, a throughput problem can become a completeness problem.

Where lag tips into data loss: buffer overflow, log purging, and source-specific traps

A delayed event can still arrive as long as its source is available for replay. Buffer overflow can cause DMS to drop events rather than apply backpressure, without a built-in mechanism to detect or replay what was lost. Target freshness is no longer the only concern when the system can exhaust the resources needed to preserve pending changes.

Oracle redo and archive logs can be purged before DMS processes them. AWS DMS documentation states that SQL Server events may be lost when they are archived from the active transaction log to the backup log or truncated before DMS reads them. Extending retention can help with the Oracle risk, but storage constraints and organizational policies can make that impractical.

PostgreSQL has a constraint on change capture: DMS ignores updates and deletes on tables without primary keys by default, although REPLICA IDENTITY FULL provides a workaround. It does not capture TRUNCATE operations at all. A target can therefore diverge even when the team is not facing the same overload or log-purging conditions that affect another source.

LOB columns, including large JSON objects and text fields, add risk at the source because each change event runs a separate lookup query. Under load, those lookups can cause locks and leave a task silently hanging without actionable diagnostics. More buffer space does not resolve an unsupported operation, and a table setting does not preserve purged logs. The longer the data diverges, the harder it is to reconcile without a full reload, which puts data integrity at risk while it runs.

Schema changes mid-stream: why DMS silently corrupts rather than fails loudly

A DMS task can continue running “successfully” after a source schema change while omitting new fields or misaligning data types at the target. A visible crash is easier to recognize. Dropping columns, changing data types, and renaming columns can cause silent failure or stop replication altogether.

For PostgreSQL, part of the difficulty comes from the underlying WAL decoding mechanism. The omission of DDL, including an ALTER TABLE operation, from the change stream is a constraint of logical decoding shared by tools built on WAL decoding. The distinction is how a replication service handles the gap. DMS has no built-in schema versioning or validation support to bridge it for the operator.

AWS’s remediation workflow requires stopping the task, manually applying DDL to the target, and inspecting CloudWatch logs to identify failed statements. Depending on the scenario, recovery then uses aws dms start-replication-task --start-replication-task-type reload-target to restart the full task or aws dms reload-tables to reload specific tables while the task is running. The process remains manual, with no rollback guarantee.

DMS also maintains no schema history or version tracking. That absence complicates diagnosis after downstream consumers discover incomplete data. The affected period may be difficult to establish. Without a record of schema versions, operators have less support for determining when the target stopped matching the source’s structure. This makes schema volatility a separate fitness criterion from write volume, because a quiet table can still change shape.

DMS Serverless removes the operational knobs that partially compensated for these limits

DMS Serverless can run ongoing CDC with both full-load-and-cdc and cdc-only task types. Its limitations concern the controls and capabilities available around those tasks, including the absence of custom CDC start points. Support for ongoing CDC should therefore not be mistaken for removal of the replication constraints described above.

The provisioned instance model gives practitioners controls for manual sharding, instance sizing, and per-task configuration that partially compensate for limited apply parallelism. Moving away from that model does not itself fix the apply bottleneck. Serverless changes the available operating choices while preserving the original design intent. It also does not support views for either CDC or full-load tasks, limiting how teams can shape downstream data without changing the source schema.

Teams must weigh the hands-on work that provisioned DMS needs against the fewer controls and limits on what Serverless can do. Neither choice supplies a general escape from the workload assessment. A team weighing Serverless must still check how replication works for its application, even if it has less infrastructure to manage.

The legitimate case for keeping DMS in production, and where it holds

Some teams successfully run DMS as a continuous replication layer, particularly on AWS-native paths such as RDS to Redshift or RDS to another RDS instance. Those deployments are a legitimate use of the service. The workload must stay within a range where the limitations are tolerable and the operating cost is understood.

Disaster recovery and cross-region read replicas can fit that range when change volumes are moderate and predictable and there is no strict latency SLA. The team pays continuously for the provisioned instance and accepts manual intervention as a known cost. That can be a defensible trade-off. In this setting, a delay or task interruption does not necessarily violate the system’s stated requirements.

Low-write tables with stable schemas are less likely to run into the overload and schema-change problems described above. They do not continually press the apply loop or force target DDL maintenance. Schema stability narrows one important class of risk. Predictable change volume similarly makes backlog behavior less demanding than sustained high-frequency writes, although source-specific capture restrictions still need to fit the data being replicated.

AWS explicitly provides no SLA for CDC replication latency and advises against DMS CDC for use cases requiring sub-second or guaranteed low-latency replication. That policy defines an important boundary for production use. A working deployment is not a latency guarantee. DMS holds when the workload is AWS-native, change volume is low-to-moderate, schema changes are infrequent, and the team can absorb intervention when tasks fall behind or halt.

What to look for in fan-in CDC replication when DMS's design constraints exceed the workload's limits

For fan-in CDC replication from multiple operational databases into a single warehouse, the assessment must cover each source’s behavior as well as the shared destination’s needs. Consolidating streams from five production databases into one data warehouse is not simply a question of connecting five sources. Oracle log retention, PostgreSQL table identity, and schema changes each need to be handled in their own way, so a replication path that works says little about how well the others will work.

A replication tool must be evaluated against the requirements that DMS cannot reliably absorb for the proposed workload. Those criteria include sustained change throughput, latency expectations, schema evolution, recovery from missing events, and treatment of sources without primary keys. Operational cost, including routine task maintenance, belongs in the same assessment.

Replication lag first grows faster than it recovers, and task restarts become routine. Schema changes then require coordinated downtime to resolve. Silent gaps may become visible to downstream consumers only when they notice inconsistencies. These signals indicate that the team is spending increasing effort compensating for the design rather than simply operating within its intended range.

AI agents, customer-facing dashboards, and A/B testing frameworks are particularly exposed when they depend on a DMS-replicated warehouse. For those consumers, latency spikes and missing columns can be correctness failures. Sub-minute latency requirements also warrant scrutiny given the absence of a CDC latency SLA. The decision is whether the cost of staying within DMS’s constraints remains lower than adopting a tool designed for the actual replication requirement. Making that comparison before recurring restarts or silent gaps become normal allows a team to plan for an architectural limit before it causes an outage.