Stata merge command: choosing between 1:1 and m:1 joins without duplicating data

The short answer: pick the merge type that matches your key cardinality

If you are combining two Stata datasets and one file contains many observations per identifier while the other contains exactly one, use m:1. If both files contain at most one observation per identifier, use 1:1. Choosing the wrong type either produces an error or silently duplicates rows, which is why the declaration is not optional in modern Stata.

How merge matches observations

The merge command joins the dataset currently in memory—called the master—with a dataset stored on disk—called the using dataset. Stata compares the values of one or more key variables that you name after the merge type. For every observation in the master, Stata looks for a corresponding key value in the using file.

Stata records the outcome in a new system variable called _merge. The codes are:

• 1 = observation appeared only in the master dataset.
• 2 = observation appeared only in the using dataset.
• 3 = observation matched in both datasets.

Because _merge is generated automatically, you can audit the join immediately after the command runs.

Worked example: attaching lookup attributes with m:1

Suppose transactions.dta holds sales records with many rows per client, and lookup.dta holds one row per client with attributes such as region and account tier. The key variable is client_id. Run the following in the Stata Command window or inside a do-file after opening the master file. You need read access to both .dta files and write access to the current working directory if you intend to save the merged result:

* Open the master dataset first
use transactions.dta, clear

* Perform the many-to-one merge
merge m:1 client_id using lookup.dta

* Inspect the match distribution
tab _merge

In this example, transactions.dta is the master and lookup.dta is the using dataset. Because client_id is unique in the lookup file, each transaction receives the correct region and tier. If a transaction references a client_id that is absent from the lookup, _merge will be 1 and the new attribute variables will contain missing values for that row.

Before running the merge, you can confirm that the key is unique in the using dataset with:

isid client_id

If isid returns an error, the m:1 assumption is violated and the merge will either fail or produce duplicated observations.

When 1:1 is the correct choice

Use 1:1 when both datasets contain at most one observation per key. A typical case is merging two survey waves keyed on respondent ID. The syntax is parallel:

use wave1.dta, clear
merge 1:1 resp_id using wave2.dta
tab _merge

If either file accidentally contains duplicate keys, Stata will exit with an error rather than guessing how to combine the rows. That safety behavior is deliberate: a 1:1 merge is meant to align records one-to-one, not to aggregate or replicate them.

Diagnostic decision: reading _merge before you proceed

After any merge, run tab _merge to see how many observations fell into each category. The practical decision tree is:

_merge value	Meaning	Common action
3	Matched in both	Keep; the join succeeded for these rows.
1	Master only	Investigate missing lookup records or expected non-matches.
2	Using only	Decide whether to retain unmatched using rows or drop them.

If you want to keep only matched pairs, you can filter with keep if _merge==3. If you need to preserve unmatched master rows, leave them in place. The _merge variable itself should be dropped or renamed before you attempt another merge on the same in-memory dataset, because Stata will refuse to overwrite the existing _merge.

Limits and common mistakes

Type mismatches on the key variable

Stata requires the key variable to have the same storage type in both datasets. If client_id is numeric in the master but string in the using file, the merge stops with a type mismatch error. You can inspect the type with describe client_id in each dataset before merging. To fix a mismatch, convert the key in one file using tostring or destring, or recreate the key with a consistent type.

Omitting the merge type

Older Stata versions may allow a merge without an explicit 1:1, 1:m, or m:1 declaration, but doing so risks unexpected duplication or errors. Always state the cardinality explicitly so Stata can validate your assumption about key uniqueness.

Leftover _merge from a previous join

If you chain multiple merges, the first merge creates _merge. A second merge command will fail unless you first remove or rename that variable:

drop _merge
* or
rename _merge merge_source

State changes and preservation

The merge command modifies the dataset in memory. It does not alter the using file on disk, but the master dataset in memory gains new variables and possibly new observations. If you need to return to the pre-merge state, either save the original master under a different name before merging, or wrap the operation in preserve and restore:

preserve
merge m:1 client_id using lookup.dta
* ... inspect or analyze ...
restore

After restore, the in-memory data reverts to the state before the merge.

Verifying the final result

A practical check after an m:1 merge is to confirm that no unexpected duplication occurred. Count observations before and after the merge; in a pure m:1 lookup join, the observation count should not increase unless the using dataset contained rows absent from the master. You can also spot-check a few keys by listing the joined variables for known identifiers.