Do not null destination row values when source deleted
How do we configure Stitch CDC Log-Based Incremental Replication (from MongoDB Atlas to AWS RDS PostgreSQL) to not null values in destination rows when a source document is deleted?
We end up with rows like this:
_id
_sdc_batched_at
_sdc_extracted_at
_sdc_received_at
_sdc_sequence
_sdc_table_version
name
_sdc_deleted_at
687a35b9606062c59c5a5428
2026-02-19 19:12:16.465+00
2026-02-19 19:04:11.522+00
2026-02-19 19:04:31+00
1771527862209286200
1771513244411
ACME Inc
NULL
687a35f9606062c59c5a67ae
2026-02-19 19:12:16.466+00
2026-02-19 19:04:11.522+00
2026-02-19 19:04:31+00
1771527862209315701
1771513244411
Nala Bing
NULL
698e6c34fa53f8ab7e921e4c
2026-02-20 07:02:25.878+00
2026-02-20 07:01:47.149+00
2026-02-20 07:02:09+00
1771570907959430902
1771513244411
NULL
2026-02-20 06:47:20+00
698dc416c7e4363d38349382
2026-02-20 07:02:25.878+00
2026-02-20 07:01:47.149+00
2026-02-20 07:02:09+00
1771570907959422701
1771513244411
NULL
2026-02-20 06:47:18+00
So e.g. the first row: document `687a35b9606062c59c5a5428` was deleted in MongoDB and Stitch then sets `_sdc_deleted_at` correctly but it nulls `name`. The `name` value was there before the source document was deleted and that change was replicated.
What you're seeing is actually expected behavior with log based CDC replication in Stitch.
When a document is deleted in MongoDB the change stream only includes the document's _id and some metadata about the operation it doesn't include the full document fields (like name). Because of that, Stitch has no way to retain the previous values when processing a delete.
As per the documentation, Stitch handles this by overwriting the existing row:
The primary key (_id) is preserved
_sdc_deleted_at is populated with the deletion timestamp
All other columns are set to NULL
So what you end up with is essentially a tombstone record it marks that the document was deleted, but it doesn't keep the original field values.
At the moment, there isn't a configuration option in Stitch to change this behavior for log based replication.
If retaining the field values after deletion is important for your use case, you could consider a couple of alternatives:
Use soft deletes in MongoDB Instead of deleting documents, add a field like deleted_at. This way, Stitch treats it as an update and keeps all the column values intact.
Use a different replication method Full-table replication can preserve values, but it comes with trade offs like higher load.
