Hi,
What you're seeing is expected behavior in many Fabric pipeline scenarios. While duration is one factor in CU consumption, it is not the only factor. The Capacity Metrics App calculates DataMovement CU usage based on the underlying compute resources and data movement activities involved, not just the execution time.
In your example, the 44-second DataMovement operation consuming 1080 CU likely required more intensive data movement resources than the 11–12 second operations consuming 360 CU. The source and destination types can make a significant difference. Moving data from SQL Server often involves connectors, query execution, network transfer, data serialization, and potential transformation overhead, whereas file-based operations may require fewer resources even if the runtime appears similar.
Other factors that can influence DataMovement CU consumption include:
- Data volume being transferred
- Number of rows and columns processed
- Connector type (SQL Server, SAP, APIs, files, etc.)
- Parallelism used by the pipeline
- Network and gateway involvement
- Data transformation or staging operations performed during movement
The common assumption that anything under 60 seconds consumes the same amount of capacity isn't always accurate. Fabric measures resource consumption based on workload characteristics and compute utilization, not strictly on elapsed time.
To validate whether data size is the main driver in your case, compare the amount of data moved, row counts, and source types for the 1080 CU execution versus the 360 CU executions. If the SQL Server activity transferred substantially more data or required more processing, the higher CU consumption would be expected even with a runtime under 60 seconds.
If you can share the activity type (Copy Data, Dataflow Gen2, Notebook, etc.) and approximate data volumes involved, the community may be able to provide a more precise explanation of the CU calculation for that specific workload.
Thanks,
Manoj Annavajjala
