What I noticed
I ran into a feature in Connect CDC that doesn't seem to get much attention - Journal Target Mapping. It's straightforward, but it opens up some useful patterns if you're doing more than basic replication.

How it works
Journal Target Mapping sends individual transaction rows to the target. For each insert, update, or delete, it writes the full after-row image into a target table.
Along with the row data, it can include metadata such as:
- Operation type
- Transaction ID
- Row sequence
- Source table and DBMS
- Source server
- Timestamp
- Username
So you're not just moving data, you're capturing context around every change.
Where it helps
I've seen this fit really well in a couple of scenarios:
- Audit trails - You get a detailed, row-level history of changes with enough metadata to trace what happened and when.
- Data warehouse feeds - Instead of only keeping the latest state, you can store change data in a structured way for downstream processing.
It's useful when you need visibility into changes, not just the end result.
Quality of features
There are a couple of things that make this easier to work with:
- If source and target table names match, the Journal Mapping option can automatically align tables and create column mappings.
- Batch journal inserts can reduce commit overhead on the target database, improving performance slightly in busier environments.
That combination makes it quicker to set up than I expected.
Why it stands out
Most of the time, we focus on replication to keep systems in sync. This feature shifts that mindset slightly. It lets you treat change data as something you can persist, analyse, and reuse.
Have you used Journal Target Mapping in your setups, or do you handle audit and change tracking differently?🤔
------------------------------
Adhitya Maya
*Precisely Software Inc.
------------------------------