Stata 17 Merge: Should Duplicate Keys Trigger a Stop or Continue During Many‑to‑Many Merges?

Direct answer

Stata’s merge command never stops when it encounters duplicate key values in either the master or the using dataset. It always proceeds and creates a full many‑to‑many (Cartesian) match for each shared key.

Confirmed facts

• Execution continues. No error or automatic halt is issued; the command finishes and returns a dataset that contains every pairwise combination of observations sharing the same key.
• No aggregation. Stata does not collapse, summarize, or otherwise reduce duplicate rows. The user must clean or aggregate the data beforehand if a one‑to‑one or one‑to‑many result is required.
• Cross‑platform and cross‑version consistency. This behavior is identical on Windows, macOS, and Linux, and has not changed between Stata 16 and Stata 17.

Why it matters

Because the merge silently expands the observation count (e.g., 2 duplicates in master × 3 duplicates in using = 6 rows for that key), downstream analyses can be distorted if the duplicates are unintentional. Memory consumption also grows with the size of the Cartesian product.

Verification steps (run in a test session)

* Create master dataset
clear
input id value
1 10
1 20
2 30
end
save master, replace

* Create using dataset
clear
input id extra
1 100
1 200
1 300
2 400
end
save using, replace

* Perform many‑to‑many merge
use master, clear
merge m:m id using using

* Inspect results
list
count if _merge==3   // should be 2*3 + 1*1 = 7 observations

The _merge variable will show only value 3 (matched in both) and the observation count will equal the product of duplicate counts for each key.

One diagnostic detail that could change the recommendation

If the duplicate groups are extremely large (thousands of rows per key), the Cartesian product may exceed available memory. In that case, confirm the maximum duplicate count per key before merging, and consider collapsing or sampling first.

Assumptions & uncertainty

• Assumes a standard merge m:m call without the force or noupdate options, which do not alter the duplicate‑key behavior.
• No known Stata 17 patch changes this behavior; if a future release introduces a stoponduplicate option, the answer would need updating.