What I noticed
While working through replication internals, I spent some time understanding shadow tables. At first they look like background metadata, but they are actually central to how CDC keeps data consistent, especially in bi-directional setups.
What shadow tables store
Each replicated table has its own shadow table, with one row per distribution key.
That row tracks:
- Distribution key values to identify the row
- Last operation type (I, U, D)
- GMT timestamp of the last update from both local and remote sources
- Where the last update came from
It is not storing history. It is storing the latest known state for that key so CDC can make decisions quickly.
What happens during apply
When CDC applies a row on the target, it checks the shadow table using the primary key and compares it with the incoming change.
It is basically asking one thing:
Is this update newer than what I already have?
If protected collision resolution is enabled, CDC uses the timestamp to pick the latest update.
In practice, this becomes a simple rule - latest update wins.
Why this matters in bi-directional setups
This is what makes many-to-many replication safe.
If the same row is updated in two places at nearly the same time, shadow tables help detect it and decide which one should win. Without this layer, some of these conflicts would never be detected and data could drift out of sync.
Things that stood out
A few behaviors became clearer while testing and reading:
- Shadow rows are created only when data changes, not preloaded
- Each update overwrites the previous state for that key
- A no-op update (same value) can still update the shadow table but not replicate, which can lead to mismatch between systems
That last one is easy to miss and shows up only during deeper troubleshooting.
Operational impact
Shadow tables grow over time as more rows are updated. In some systems, they can reach the same size as the source tables or even exceed it.
They also need careful cleanup. If you clean them, both sides need to be handled at the same time to avoid issues.
Shadow tables are not just supporting structures. They are the decision layer that controls whether a change should be applied or ignored.
Understanding how they work makes it much easier to reason about collision handling and tricky replication behavior.
Have you run into scenarios where shadow tables explained unexpected replication behavior?
*Precisely Software Inc.