Two tables, one goal: bring the data together. But depending on how those tables relate to each other, you need very different tools. Reach for the wrong one, and you'll either end up with a table full of blank columns or duplicated rows that quietly wreck your totals. Understanding the difference between Merge vs. Append in Power Query is essential for creating accurate reports and efficient data models. This is, by a wide margin, the question beginners ask most often when they start working with Power Query, so let's settle it for good.
The short version: Merge joins tables sideways using a shared key. Append stacks tables on top of each other. Everything else follows from that one distinction.
Ask yourself: do these tables describe the same kind of records (stack them Append), or do they describe related records that need to be linked (join them Merge)?
Merge: Combining Tables Sideways
Merging is Power Query's equivalent of a SQL join, or a more powerful version of Excel's VLOOKUP. You use it when two tables hold related but different information, connected by a common column, such as a Customer ID or Product Key. The result is a wider table: the same number of rows as your primary table, with new columns pulled in from the second source.
| Table A | Customer ID | + | Customer ID | Table B |
| Name | Region | ↔ | Order Total | Order Date |
Classic example: Table A has customer names and regions; Table B has order totals and dates, linked by Customer ID. Merging lets you pull order information directly onto the customer table without duplicating a single row.
How to do it:
- Select your primary table, then go to Home → Merge Queries (or Merge Queries as New to keep the original untouched).
- Choose the second table, then click the matching column in each table's preview hold Ctrl to select multiple key columns.
- Pick a Join Kind (see the table below) and click OK.
- A new column appears containing the related table's data. Click the expand icon to choose which fields to bring in.
Worked example: merging Customers with Orders
Table 1 : Customers
| Customer ID | Name | Region |
| 101 | Aditi Sharma | West |
| 102 | Ben Walker | East |
| 103 | Chen Wei | North |
Table 2 : Orders
| Customer ID | Order Total | Order Date |
| 101 | 4,200 | 2026-04-02 |
| 102 | 1,150 | 2026-04-05 |
Result after merging on Customer ID (Left Outer join) note Chen Wei has no matching order, so the new columns come back blank
| Customer ID | Name | Region | Order Total | Order Date |
| 101 | Aditi Sharma | West | 4,200 | 2026-04-02 |
| 102 | Ben Walker | East | 1,150 | 2026-04-05 |
| 103 | Chen Wei | North | – | – |
The Six Join Kinds
The Join Kind you choose determines exactly which rows survive the merge this is where most mistakes happen, so it's worth knowing all six.
| Join Kind | Rows Kept | Typical Use |
| Left Outer (default) | All rows from the first table, plus matches from the second | Enrich a primary table without losing any of its rows |
| Right Outer | All rows from the second table, plus matches from the first | Same as Left Outer, viewed from the other table |
| Full Outer | All rows from both tables, matched where possible | Combine two tables and see everything, matched or not |
| Inner | Only rows that match in both tables | Keep only records that exist in both sources |
| Left Anti | Only rows from the first table with no match in the second | Find what's missing — e.g. orders with no customer record |
| Right Anti | Only rows from the second table with no match in the first | Find the reverse mismatch |
Append: Stacking Tables Vertically
Appending is the simpler of the two conceptually closer to copying one spreadsheet and pasting it beneath another. It's used when you have multiple tables that share the same structure (the same column names and, ideally, the same data types) and you want to consolidate them into one longer table.
| Date | Region | Product | Sales |
| Jan | East | Widget | 120 |
| Feb | East | Widget | 140 |
| Table B stacks directly beneath Table A same column structure | |||
| Mar | West | Gadget | 95 |
| Apr | West | Gadget | 110 |
Classic example: separate monthly sales exports January, February, March each with identical columns. Appending stacks them into a single table covering the full quarter, ready to summarize.
How to do it:
- Select your first table, then go to Home → Append Queries (choose Two Tables, or Three or More for several at once).
- Choose the additional table(s) to stack beneath the first.
- Click OK Power Query adds the rows underneath, matching columns by name.
- If a column exists in one table but not another, Power Query still appends, filling the missing values with null worth double-checking column names match exactly first.
Worked example: appending Jan Sales with Feb Sales
Table 1 : Jan Sales
| Region | Product | Sales |
| East | Widget | 120 |
| West | Gadget | 95 |
Table 2 : Feb Sales
| Region | Product | Sales |
| East | Widget | 140 |
| West | Gadget | 110 |
Result after appending same three columns, rows from both months stacked into one table
| Region | Product | Sales | Month |
| East | Widget | 120 | Jan |
| West | Gadget | 95 | Jan |
| East | Widget | 140 | Feb |
| West | Gadget | 110 | Feb |
Merge vs. Append, Side by Side
|
| Merge (Join) | Append (Stack) |
| Direction | Combines horizontally adds columns | Combines vertically adds rows |
| Requirement | A common key/column shared between tables | Same column structure across tables |
| SQL equivalent | JOIN | UNION ALL |
| Result shape | Wider table, same or similar row count | Longer table, same column count |
| Classic example | Adding customer details to an orders table via CustomerID | Combining Jan, Feb, Mar sales files into one table |
Append does not remove duplicates automatically run Remove Duplicates afterward if needed. Merge's default Left Outer join silently keeps every row from your primary table even when there's no match, so always check the new column for blank (null) values before assuming everything matched. ), or do they describe related records that need to be linked (join them Merge)?
Conclusion
Merge and Append solve two completely different problems, and once you can picture them one growing a table sideways, the other stacking tables upward the confusion tends to disappear for good. When your tables describe related-but-different things, merge them on a shared key. When your tables describe more of the same thing, append them into one longer list.
Keep the side-by-side comparison above bookmarked, and the next time you're staring at two queries wondering how to combine them, the answer will take seconds instead of guesswork.