Insert seeds, Merge converges, Clean deletes

The three Write Strategies are radio buttons in the same step. They are not three flavours of the same operation — they are three different applications wearing the same UI.

4 min read

Every Copy action asks you to pick one of three Write Strategies. The UI presents them as equal-weight choices. Their effect on the target environment is anything but equal.

The pitfall in one line
Pick Merge when you meant Insert and matched rows in the target are silently overwritten by source values. Pick Clean when you meant Merge and target-only rows are gone.

The three strategies, in one breath each

Insert — every record from the source is added to the target as a new row. The target keeps everything it already had. Use this for seeding a fresh environment or appending a known-new batch.

Merge — rows are matched on the entity's key attributes. Matched rows are updated in place; unmatched rows are inserted. Target-only rows (rows in the target that the source does not know about) are kept. Use this when you want the target to converge towards the source without losing anything the target acquired on its own.

Clean — existing rows in the selected entities are deleted from the target, and then the source data is loaded. There is no merging, no matching, no preservation. Use this when you genuinely want a fresh-from-source replica and you control the target end-to-end.

The three questions that pick the strategy

Ask, in order: (1) does the target hold any data that exists nowhere else? If yes, Clean is wrong — full stop. (2) Should source updates overwrite the same rows in the target? If yes, Merge. If no, Insert with a filter so duplicates are not created. (3) Is the target an empty environment you control, where "fresh from source" is the goal? Then Clean is fine and gives the most predictable result.

Do
  • ·Use Insert to seed a sandbox or add a known-new batch.
  • ·Use Merge for ongoing sync between environments where target-only data exists.
  • ·Use Clean for non-production environments you are intentionally replacing.
  • ·Read the strategy description in the UI — it changes when you switch radios.
Don't
  • ·Default to Clean because "it sounds tidiest". Tidy in the lab is destructive in prod.
  • ·Pick Merge without confirming the entity has the right key attributes. Bad keys = bad updates.
  • ·Switch strategy mid-iteration without a fresh test run. Strategy changes the math; old confidence does not transfer.

A concrete example

A 12,000-record customer table is being synced nightly from a source-of-truth into a downstream environment. The downstream environment has 4,000 customers only it knows about — they were created locally for an A/B test. Someone changes the strategy from Merge to Clean to "speed up the sync because Clean is simpler".

That night, Clean deletes all 16,000 rows in the target and loads the 12,000 from source. The next morning, the A/B test is gone. Recovery requires a database restore — Clean is the only one of the three strategies with no in-product undo.

Rule of thumb
If the target holds anything that does not exist in the source, never Clean. Merge is what you wanted.
Still need help?
If this article does not solve it, the DMM Infinity team is one ticket away.
Submit a ticket