Unique key for merge behavior in dbt - Time & Space Complexity
When using dbt to merge data, it's important to understand how the unique key affects performance.
We want to know how the time to merge grows as the data size increases.
Analyze the time complexity of this dbt merge operation.
merge into target_table as t
using source_table as s
on t.unique_key = s.unique_key
when matched then update set
t.value = s.value
when not matched then insert (unique_key, value) values (s.unique_key, s.value);
This code merges data from source_table into target_table using a unique key to match rows.
Look at what repeats during the merge.
- Primary operation: Matching rows by unique key between source and target tables.
- How many times: Once for each row in the source table.
As the number of rows in the source table grows, the merge checks each row against the target.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 key lookups and updates/inserts |
| 100 | About 100 key lookups and updates/inserts |
| 1000 | About 1000 key lookups and updates/inserts |
Pattern observation: The work grows roughly in direct proportion to the number of rows to merge.
Time Complexity: O(n)
This means the time to merge grows linearly with the number of rows in the source table.
[X] Wrong: "The merge will be constant time because the unique key makes matching instant."
[OK] Correct: Even with a unique key, the database must check each source row once, so time grows with data size.
Understanding how merge operations scale helps you explain data pipeline efficiency clearly and confidently.
What if the unique key was not indexed? How would the time complexity change?
Practice
What is the main purpose of the unique_key in dbt's merge behavior?
Solution
Step 1: Understand the role of unique_key in merge
The unique_key tells dbt which rows in the target table correspond to rows in the source table during a merge operation.Step 2: Identify the correct behavior of unique_key
It helps dbt decide whether to update existing rows or insert new rows based on matching keys.Final Answer:
To identify which rows to update or insert during a merge -> Option DQuick Check:
unique_key matches rows for merge = D [OK]
- Thinking unique_key sorts data
- Believing unique_key creates columns
- Confusing unique_key with deleting rows
Which of the following is the correct way to specify a composite unique_key in a dbt model's merge config?
merge:
unique_key: ?Solution
Step 1: Recall syntax for composite unique_key
dbt expects a list of column names for composite keys, written as ['col1', 'col2'].Step 2: Match syntax options
['id', 'date'] uses a list syntax with square brackets and quotes, which is correct.Final Answer:
['id', 'date'] -> Option AQuick Check:
Composite unique_key = list of columns [OK]
- Using a string with commas instead of a list
- Using curly braces which is invalid syntax
- Trying to add columns with + operator
Given the following dbt merge config:
merge:
unique_key: 'user_id'And source data:
| user_id | value |
|---------|-------|
| 1 | 100 |
| 2 | 200 |
| 1 | 300 |What will happen when merging into a target table with existing user_id 1 and 2?
Solution
Step 1: Understand unique_key behavior with duplicates in source
dbt uses unique_key to match rows. If source has duplicates, the last row usually overwrites previous ones during merge.Step 2: Analyze the source data effect
Two rows with user_id 1 exist; the last row with value 300 will update the target row with user_id 1.Final Answer:
The last row with user_id 1 will update the target, overwriting previous -> Option BQuick Check:
Duplicate keys in source overwrite last row = C [OK]
- Expecting error on duplicate keys in source
- Thinking all duplicates insert as new rows
- Assuming only first duplicate updates
Consider this dbt merge config snippet:
merge:
unique_key: ['id']But the source data has duplicate id values. What is the likely issue?
Solution
Step 1: Identify problem with non-unique keys in merge
Unique_key must uniquely identify rows. If duplicates exist, dbt cannot correctly match rows.Step 2: Understand merge behavior with duplicates
Duplicates cause merge to fail or produce wrong updates because dbt doesn't know which row to update.Final Answer:
Merge will fail or produce incorrect results due to non-unique keys -> Option AQuick Check:
Non-unique keys cause merge failure = A [OK]
- Assuming merge ignores duplicates silently
- Thinking merge creates new columns for duplicates
- Believing merge auto-removes duplicates
You want to merge data from a source table into a target table using dbt. The source has columns user_id, event_date, and event_type. You want to update existing rows only if both user_id and event_date match. Which unique_key should you use?
Solution
Step 1: Identify columns needed to uniquely match rows
Since updates depend on matching both user_id and event_date, both must be part of unique_key.Step 2: Choose correct unique_key syntax
unique_key: ['user_id', 'event_date'] correctly uses a list with both columns to uniquely identify rows for merge.Final Answer:
unique_key: ['user_id', 'event_date'] -> Option CQuick Check:
Composite key matches both columns = B [OK]
- Using only user_id when event_date is needed
- Using event_type which is not unique key
- Mixing wrong columns in unique_key
Ready to prove it?
Pass the test and this pattern moves unknown
