Yazdan's avatar
Yazdan
Advocate II
3 months ago
Status:
New

Fabric Copy Activity Upsert Needs Native Audit Columns

๐— ๐—ถ๐—ฐ๐—ฟ๐—ผ๐˜€๐—ผ๐—ณ๐˜ ๐—™๐—ฎ๐—ฏ๐—ฟ๐—ถ๐—ฐ ๐—–๐—ผ๐—ฝ๐˜† ๐—”๐—ฐ๐˜๐—ถ๐˜ƒ๐—ถ๐˜๐˜† + ๐——๐—ฒ๐—น๐˜๐—ฎ ๐—จ๐—ฝ๐˜€๐—ฒ๐—ฟ๐˜ is honestly one of the most underrated features in Fabric for high-performance operational data loading.

 

We can now:

โ€ข Read directly from sources such as SQL Server / SQL DB
โ€ข Write directly into Lakehouse Delta Tables
โ€ข Use native Upsert mode
โ€ข Avoid Spark notebooks completely
โ€ข Avoid Parquet staging/intermediate layers
โ€ข Achieve very fast sync performance with only ONE Copy Activity

 

Iโ€™m currently using this approach to dynamically load and merge data from multiple SQL Server store databases into consolidated Delta tables in Microsoft Fabric Lakehouse.

However, there is one very important feature still missing from Copy Activity Upsert.

 

๐—œ ๐˜„๐—ผ๐˜‚๐—น๐—ฑ ๐—น๐—ผ๐˜ƒ๐—ฒ ๐˜๐—ผ ๐˜€๐—ฒ๐—ฒ ๐—ป๐—ฎ๐˜๐—ถ๐˜ƒ๐—ฒ ๐˜€๐˜‚๐—ฝ๐—ฝ๐—ผ๐—ฟ๐˜ ๐—ณ๐—ผ๐—ฟ ๐—ฎ๐˜‚๐˜๐—ผ-๐—บ๐—ฎ๐—ป๐—ฎ๐—ด๐—ฒ๐—ฑ ๐—ฎ๐˜‚๐—ฑ๐—ถ๐˜ / ๐——๐—ช ๐—ฐ๐—ผ๐—น๐˜‚๐—บ๐—ป๐˜€ during Upsert operations.

My requirement is:

In the destination Delta table, I need these columns:

โ€ข DW_DATE_INSERT
โ†’ Datetime when a NEW record is inserted through Upsert

โ€ข DW_DATE_UPDATE
โ†’ Datetime when an EXISTING record is updated through Upsert

โ€ข DW_LOAD_DATE
โ†’ Maximum of DW_DATE_INSERT and DW_DATE_UPDATE
(meaning the latest insert/update datetime)

 

Expected behavior:

โ€ข If INSERT occurs:

DW_DATE_INSERT should be populated

DW_DATE_UPDATE should remain NULL

โ€ข If UPDATE occurs:

DW_DATE_UPDATE should be updated

DW_DATE_INSERT should remain unchanged with its original value

 

Currently, adding these columns dynamically in the Source โ†’ Additional Columns section is NOT a solution.

Why?

Because these datetime values change every execution, the Upsert process detects every row as changed and re-updates all records again and again, even when business data has not changed.

 

Of course, I know this can be handled using Spark / Notebook MERGE logic.

But the whole beauty of this approach is:

๐—ก๐—ผ ๐—ป๐—ผ๐˜๐—ฒ๐—ฏ๐—ผ๐—ผ๐—ธ๐˜€.
๐—ก๐—ผ ๐—ฆ๐—ฝ๐—ฎ๐—ฟ๐—ธ ๐˜€๐˜๐—ฎ๐—ฟ๐˜๐˜‚๐—ฝ ๐—น๐—ฎ๐˜๐—ฒ๐—ป๐—ฐ๐˜†.
๐—ก๐—ผ ๐—ฒ๐˜…๐˜๐—ฟ๐—ฎ ๐—บ๐—ฒ๐—ฟ๐—ด๐—ฒ ๐—น๐—ฎ๐˜†๐—ฒ๐—ฟ.
๐—๐˜‚๐˜€๐˜ ๐—ผ๐—ป๐—ฒ ๐—ณ๐—ฎ๐˜€๐˜ ๐—–๐—ผ๐—ฝ๐˜† ๐—”๐—ฐ๐˜๐—ถ๐˜ƒ๐—ถ๐˜๐˜†.

 

It would be amazing if Microsoft could add native insert/update audit column handling directly inside Copy Activity Upsert for Delta Lakehouse tables.

This would make Copy Activity even more powerful for very fast enterprise operational sync workloads.

If you think this feature would be useful, please vote/support this idea so we can hopefully get it added to Fabric ๐Ÿ™Œ

 

#MicrosoftFabric #DataEngineering #DeltaLake #Lakehouse #ETL #ELT #OneLake #SQLServer #Fabric #Microsoft #AnalyticsEngineering

2 Comments

Recent ideas