<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Tip: Why your Delta MERGE fails with &amp;quot;multiple source rows matched&amp;quot; (and the simple fix) in Data Engineering</title>
    <link>https://community.databricks.com/t5/data-engineering/tip-why-your-delta-merge-fails-with-quot-multiple-source-rows/m-p/170188#M56249</link>
    <description>&lt;P&gt;Hi everyone &lt;span class="lia-unicode-emoji" title=":waving_hand:"&gt;👋&lt;/span&gt;&lt;/P&gt;&lt;P&gt;If you run incremental loads with MERGE INTO on Delta tables, you may have seen a merge fail with an error saying multiple source rows matched the same target row.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Why it happens&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;A MERGE compares each row in your source batch to your target table using a key, like customer_id. If the source contains two or more rows with the same key, Delta has no way of knowing which one should update the target, so it stops rather than guess. This comes up a lot with CDC feeds, event streams, and batches that capture several changes to the same record between runs.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;The fix&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Before merging, reduce the source to one row per key, keeping the most recent version. Rank rows within each key by a timestamp and keep only the top one. In Databricks SQL, QUALIFY makes this a one-liner you can add to your source query:&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;QUALIFY ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY updated_at DESC) = 1&lt;/STRONG&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;P&gt;Then run your MERGE against that cleaned-up result as usual.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;A few gotchas&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Make sure your ordering is reliable. If two rows can share the same timestamp, add a tiebreaker such as a sequence number so the "latest" row is always the same one.&lt;/P&gt;&lt;P&gt;Avoid simply dropping duplicates by key. Generic dedup functions keep an arbitrary row, not the newest, which can quietly write stale data into your table.&lt;/P&gt;&lt;P&gt;If you're using Lakeflow Declarative Pipelines (formerly Delta Live Tables), the AUTO CDC / APPLY CHANGES feature handles this ordering for you, which is worth a look for CDC-heavy workloads.&lt;/P&gt;&lt;P&gt;Hope this saves someone a debugging session! How do you handle duplicates before merging? I'd love to hear other approaches in the comments.&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;</description>
    <pubDate>Tue, 29 Sep 2026 19:44:59 GMT</pubDate>
    <dc:creator>LiresaFerizaj</dc:creator>
    <dc:date>2026-09-29T19:44:59Z</dc:date>
    <item>
      <title>Tip: Why your Delta MERGE fails with "multiple source rows matched" (and the simple fix)</title>
      <link>https://community.databricks.com/t5/data-engineering/tip-why-your-delta-merge-fails-with-quot-multiple-source-rows/m-p/170188#M56249</link>
      <description>&lt;P&gt;Hi everyone &lt;span class="lia-unicode-emoji" title=":waving_hand:"&gt;👋&lt;/span&gt;&lt;/P&gt;&lt;P&gt;If you run incremental loads with MERGE INTO on Delta tables, you may have seen a merge fail with an error saying multiple source rows matched the same target row.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Why it happens&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;A MERGE compares each row in your source batch to your target table using a key, like customer_id. If the source contains two or more rows with the same key, Delta has no way of knowing which one should update the target, so it stops rather than guess. This comes up a lot with CDC feeds, event streams, and batches that capture several changes to the same record between runs.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;The fix&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Before merging, reduce the source to one row per key, keeping the most recent version. Rank rows within each key by a timestamp and keep only the top one. In Databricks SQL, QUALIFY makes this a one-liner you can add to your source query:&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;QUALIFY ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY updated_at DESC) = 1&lt;/STRONG&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;P&gt;Then run your MERGE against that cleaned-up result as usual.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;A few gotchas&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Make sure your ordering is reliable. If two rows can share the same timestamp, add a tiebreaker such as a sequence number so the "latest" row is always the same one.&lt;/P&gt;&lt;P&gt;Avoid simply dropping duplicates by key. Generic dedup functions keep an arbitrary row, not the newest, which can quietly write stale data into your table.&lt;/P&gt;&lt;P&gt;If you're using Lakeflow Declarative Pipelines (formerly Delta Live Tables), the AUTO CDC / APPLY CHANGES feature handles this ordering for you, which is worth a look for CDC-heavy workloads.&lt;/P&gt;&lt;P&gt;Hope this saves someone a debugging session! How do you handle duplicates before merging? I'd love to hear other approaches in the comments.&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;</description>
      <pubDate>Tue, 29 Sep 2026 19:44:59 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/tip-why-your-delta-merge-fails-with-quot-multiple-source-rows/m-p/170188#M56249</guid>
      <dc:creator>LiresaFerizaj</dc:creator>
      <dc:date>2026-09-29T19:44:59Z</dc:date>
    </item>
    <item>
      <title>Re: Tip: Why your Delta MERGE fails with "multiple source rows matched" (and the simple fi</title>
      <link>https://community.databricks.com/t5/data-engineering/tip-why-your-delta-merge-fails-with-quot-multiple-source-rows/m-p/170204#M56256</link>
      <description>&lt;P&gt;Great breakdown! That exact error has tripped up many a CDC pipeline. When working in PySpark, I typically use a similar window approach with row_number() and a strict tiebreaker like a sequence number before registering the temporary view for the merge. The QUALIFY clause in Databricks SQL is a fantastic shortcut though definitely saving that trick to clean up some verbose queries!&lt;/P&gt;</description>
      <pubDate>Wed, 30 Sep 2026 05:51:57 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/tip-why-your-delta-merge-fails-with-quot-multiple-source-rows/m-p/170204#M56256</guid>
      <dc:creator>monika532lara</dc:creator>
      <dc:date>2026-09-30T05:51:57Z</dc:date>
    </item>
  </channel>
</rss>

