DMS CDC to Redshift — Three Bugs Making CDC Non-Functional

Question

We are running DMS replication from **Aurora PostgreSQL 15.x** to **Redshift Provisioned (RA3)** in `eu-central-1`. After the Redshift maintenance update to **v1.0.232773 (patch 199)** on March 8, 2026, CDC replication is completely broken across all our tasks.

We have identified **three separate issues** that together make CDC non-functional. Two are regressions introduced by the Redshift patch; one is a long-standing DMS limitation that compounds the problem.

**Environment:**
- Source: Aurora PostgreSQL 15.x (also reproduced on RDS PostgreSQL 16.x)
- Target: Amazon Redshift Provisioned (RA3), `eu-central-1`
- DMS Engine: 3.5.x (latest available)
- Replication type: Full load + CDC
- Infrastructure managed via Terraform (`aws_dms_replication_task`)

---

## Bug 1: Batch-apply staging table `seg` columns created as `varchar(20)`

**Severity: Critical — breaks all CDC tasks with TEXT/UUID primary keys**

Since patch 199, DMS creates `seg` columns (primary key segments) in `awsdms_changes*` batch-apply staging tables with a hardcoded `varchar(20)`, regardless of the actual source column type or length. Any PK value exceeding 20 characters overflows the column and the CDC task fails immediately.

This is a regression — the same tasks worked correctly before the Redshift maintenance window.

**Example:** A source column `id TEXT` (containing UUIDs, 36 chars) produces:
- `col1` → `varchar(49152)` (correct data column)
- `seg1` → `varchar(20)` (incorrect PK segment column — should match source type)

**Evidence from Redshift system tables:**

```sql
-- Verify seg columns are varchar(20) across all staging tables
SELECT c.relname AS staging_table, a.attname AS column_name, a.atttypmod
FROM pg_attribute a
JOIN pg_class c ON a.attrelid = c.oid
WHERE c.relname LIKE 'awsdms_changes%'
  AND a.attname LIKE 'seg%'
  AND a.atttypmod = 24;  -- atttypmod 24 = varchar(20)
```

**Evidence from `stl_load_errors` (err_code 1204 — String length exceeds DDL length):**

```
colname: seg1, col_length: 20, raw_field_value: 019cd295-d491-719d-a3d0-49d307e1b318
colname: seg6, col_length: 20, raw_field_value: 019cd1b9-69c8-72ab-a9eb-795080565457
```

---

## Bug 2: `BatchApplyEnabled=false` silently ignored

**Severity: Critical — removes the only workaround for Bug 1**

The natural workaround for Bug 1 is to disable batch apply (switching to transactional apply, which doesn't use `seg` columns). However, setting `"BatchApplyEnabled": false` in task settings is silently ignored. DMS accepts the configuration without error but continues to operate in batch-apply mode, creating `awsdms_changes*` staging tables regardless.

**Confirmed via multiple methods:**

| Method | Result |
|---|---|
| `modify-replication-task` API | Returns `modifying` status, setting silently reverts to `true` |
| Terraform `aws_dms_replication_task` resource | Same silent revert — no error, no diff |
| Delete + recreate task from scratch | Batch-apply staging tables still created |
| New DMS tasks | Same behavior |

This may also be a regression from the Redshift patch, or a pre-existing issue that was previously masked because batch apply was functioning correctly.

---

## Bug 3: PostgreSQL array column types (`TEXT[]`, `INT[]`, etc.) unsupported

**Severity: High — affects multiple tables across multiple databases**

DMS cannot replicate PostgreSQL array column types. This is not specific to the Redshift patch (we've seen this across DMS versions), but it compounds the other issues because it further limits which tables can be replicated via CDC.

**Example source table:**

```sql
CREATE TABLE my_schema.my_table (
    id UUID PRIMARY KEY,
    name TEXT NOT NULL,
    tags TEXT[] DEFAULT '{}',
    created_at TIMESTAMPTZ NOT NULL
);
```

**Observed behavior** (varies by configuration):
1. **Task error** — DMS fails with an unsupported data type error during table mapping
2. **Column silently omitted** — the `tags` column is excluded from the Redshift target without any warning in task logs
3. **Corrupt data** — the column is mapped to `VARCHAR` but the PostgreSQL array literal (`{tag1,tag2,tag3}`) is not properly serialized, causing COPY failures

---

## Combined troubleshooting (all three bugs)

| Attempt | Addresses | Result |
|---|---|---|
| Drop target tables + full reload | Bug 1 | Full load succeeds, CDC fails immediately |
| Delete + recreate DMS task | Bugs 1, 2 | `varchar(20)` reproduced; batch apply still forced |
| `BatchApplyEnabled: false` (API + Terraform) | Bugs 1, 2 | Silently ignored |
| `change-data-type` transformation rules | Bugs 1, 3 | Does not affect `seg` columns or array types |

---

## Current workaround

We are running **full-load-only** tasks that reload affected databases multiple times per day. This is not viable long-term:
- Data gaps between reloads (no real-time analytics)
- Full reloads are slow and expensive for large tables
- Array columns still require source-side schema modifications

---

## Questions

1. **Bug 1:** Is the `varchar(20)` staging column regression a known issue introduced in Redshift **v1.0.232773 / patch 199**? Is there a hotfix planned?
2. **Bug 2:** Is there a way to force-disable batch apply at the replication instance level, or is this a confirmed DMS bug?
3. **Bug 3:** Is PostgreSQL array type replication officially unsupported in DMS? The [documentation](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html) does not explicitly list array types as unsupported.
4. **General:** Has anyone else experienced CDC failures after the March 2026 Redshift maintenance window?
5. **Workaround:** Is there a DMS engine version or configuration combination where transactional apply (non-batch) works reliably with the Redshift target?

---

## Impact

- **All CDC replication tasks** from Aurora PostgreSQL to Redshift are non-functional since March 8
- **Multiple tables** across multiple logical databases contain array columns that cannot be replicated even under normal conditions
- We are evaluating migration to alternative CDC solutions (Debezium, Zero-ETL) but need these bugs resolved for short-term continuity

Region: `eu-central-1`. We can provide task ARNs, replication instance IDs, and CloudWatch logs to AWS support on request.

re:Post Agent · Answer

I understand you're experiencing critical CDC failures after a Redshift maintenance update. While I cannot confirm specific version-related regressions or provide information about unreleased patches, I can offer guidance based on common DMS-to-Redshift CDC issues.

**Regarding your staging table and BatchApplyEnabled concerns:**

The issues you're describing with staging table column sizing and batch apply settings are not typical expected behaviors. For CDC to function properly with Redshift targets, several prerequisites must be met:

1. **Source table requirements**: Verify that all source PostgreSQL tables have primary keys defined. For PostgreSQL sources, captured tables must have a primary key for DMS to properly process DELETE and UPDATE operations during CDC.

2. **Permissions verification**: Ensure the AWS account that DMS uses has the required permissions for both the source Aurora PostgreSQL database and the target Redshift cluster.

3. **Change log retention**: Confirm that the change logs retention period on your source database is set to at least 24 hours to prevent CDC data loss.

**Troubleshooting steps:**

- Review your DMS task logs for specific error messages related to the affected tables, particularly around the transition from full load to CDC mode.

- Monitor the **CDCLatencySource** and **CDCLatencyTarget** CloudWatch metrics for your DMS tasks to identify where delays or failures are occurring.

- Check the `awsdms_apply_exceptions` table in your Redshift database for detailed error information about failed CDC operations.

- Consider creating a validation-only task to identify data inconsistencies between source and target.

**For the column type and batch apply issues specifically:**

If you're seeing unexpected behavior with task settings being ignored or staging tables created with incorrect column definitions, I recommend:

1. Opening an AWS Support case with detailed logs, task configurations, and examples from your system table queries
2. Providing the specific DMS engine version you're using (not just the Redshift version)
3. Including CloudWatch logs and any error messages from `stl_load_errors`

This appears to be a complex issue that may require direct AWS Support investigation, especially if settings are being silently reverted and staging tables are being created with insufficient column sizes for your data types.  
**Sources**  
[Resolve data replication issues with AWS DMS migration to Amazon Redshift | AWS re:Post](https://repost.aws/knowledge-center/dms-data-replication-issues-redshift)

Stefan Szegeny · Answer

Good afternoon Kmang and aws support,

Human with over a decade on aws here, some important corrections to your question:

Bug 2 is not a bug, `BatchApplyEnabled=true` is the only possible CDC option for Redshift targets, it's mentioned somewhere in the docs, also architecturally it makes sense, OLAP vs OLTP.
Bug 3: PostgreSQL array column types (TEXT[], INT[], etc.) is another well know limitation, since redshift only supports semistructured types / type SUPER where a single value in a struct cannot be longer than 65k characters (Redshift's max character length).

Bug 1 is **where you're definitely right**, same here I've started observing this issue since March 8 (v1.0.232773 (patch 199)).

AWS support can you investigate this with the DMS engineering team properly?? The `seg1` in the `awsdms_changes*` was never a problem, tables with VARCHAR type primary keys like UUIDs were always fine, it would fit in the table.

Please let us know, I was also just about to open the same issue, and quickly checked if anyone else is experiencing this.

As a result of this bug, we're having to regularly restart our tasks, and manually adjust the managed (`awsdms_changes*`) tables, currently it remains as a critical issue for some of our production analytical workloads.

Thank you.

kmang · Answer

Some update on the matter. We did receive feedback from AWS (via our AWS Solution Architect) which I'd like to share here:

> We have identified an issue affecting your DMS task with Redshift target during CDC replication. DMS task may fail, reporting the following error:
"[TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: XX000 NativeError: 0 Message: [Redshift][ODBC Driver][Server]XX000:ERROR: Load into table'awsdms_changesXYZ". Check 'stl_load_errors' system table for details."

> -> Root Cause
This is caused by a behavioral change in the Redshift ODBC 2.x driver related to how VARCHAR column sizes are detected. During batch apply operations (UPDATEs and DELETEs), DMS creates a temporary net changes table in Redshift. Due to this driver behavior, the temporary table may be created with a column length that is insufficient to hold the primary key value, causing the load to fail. Based on our investigation, this issue currently affects tasks replicating from a PostgreSQL source where a TEXT column is part of the primary key.

> -> Workaround
There is no workaround available at this time.

> -> Resolution
Our engineering team is actively working on a fix in coordination with the Amazon Redshift team. We will update this ticket as soon as the fix is ready for deployment.

I'll update this post accordingly once there are news to share.

joshuat · Answer

Thanks for the update kmang, we're experiencing the same and have rais​e​d the i​ssu​e with s​upport but have yet to hear anything back.

We've found success manually altering the staging table column type to unblock, but it requires manual intervention multiple times per day.

huey · Answer

kmang any updates here? I found your post a couple of weeks ago because we were experiencing the same issues with CDC and have been manually doing full reloads in the interim but really hoping to get back to a more automated experience.

Anthonyt123 · Answer

We've got the exact same issue (bug 1). We have around 24 source Postgres databases using TEXT PKs, CDC is completely broken for all of them since patch 199. The DMS tasks are all green stating replication is ongoing, but all of the changes are just piling up on disk. Redshift is reporting the error "String length exceeds DDL length" as the seg1 column is being set to varchar(20) on the DMS staging tables, but we have PKs varying from anywhere between 24 to 39 characters. We're only able to move data into Redshift by doing full loads of the tasks, but it's broken all of our analytics as we rely on CDC with data updating regularly for our queries.

DMS CDC to Redshift — Three Bugs Making CDC Non-Functional

Bug 1: Batch-apply staging table `seg` columns created as `varchar(20)`

Bug 2: `BatchApplyEnabled=false` silently ignored

Bug 3: PostgreSQL array column types (`TEXT[]`, `INT[]`, etc.) unsupported

Combined troubleshooting (all three bugs)

Current workaround

Questions

Impact

Add your answer

Relevant content

Method	Result
`modify-replication-task` API	Returns `modifying` status, setting silently reverts to `true`
Terraform `aws_dms_replication_task` resource	Same silent revert — no error, no diff
Delete + recreate task from scratch	Batch-apply staging tables still created
New DMS tasks	Same behavior

Attempt	Addresses	Result
Drop target tables + full reload	Bug 1	Full load succeeds, CDC fails immediately
Delete + recreate DMS task	Bugs 1, 2	`varchar(20)` reproduced; batch apply still forced
`BatchApplyEnabled: false` (API + Terraform)	Bugs 1, 2	Silently ignored
`change-data-type` transformation rules	Bugs 1, 3	Does not affect `seg` columns or array types

DMS CDC to Redshift — Three Bugs Making CDC Non-Functional

Bug 1: Batch-apply staging table seg columns created as varchar(20)

Bug 2: BatchApplyEnabled=false silently ignored

Bug 3: PostgreSQL array column types (TEXT[], INT[], etc.) unsupported

Combined troubleshooting (all three bugs)

Current workaround

Questions

Impact

Add your answer

Relevant content

Bug 1: Batch-apply staging table `seg` columns created as `varchar(20)`

Bug 2: `BatchApplyEnabled=false` silently ignored

Bug 3: PostgreSQL array column types (`TEXT[]`, `INT[]`, etc.) unsupported