Increase transparency and reduce compute consumption of Fabric databases when used for writebacks

[Eliasaki92]

The amount of compute which is charged for writebacks via Power Apps / UDF is not equal to the amount seen in the performance summary of the Fabric database and in general way to high. It becomes hard to understand what is causing CU spikes. We were told that because of the serverless architecture initial writes / reads take a couple of seconds (apx. 30s) to turn on the backend. After 15 min without interaction it scales down again. There is no way to see nor configure the compute usage of this. We would like to have more control in the process so simple write backs do not consume a ton of compute just for spinning up the server every time. Another big downside is that the end user need to wait a significant amount of time. Every UDF also needs to spin up if it was not used for 15 min. 

We have an F4 Fabric Capacity in which we have created SQL DB workload. We also have a Power BI report in which a Power App is embedded. Power App reads data from SQL DB.

Every time end user interacts with the Power App, we see a spike in Capacity Metrics App.

It consumes almost half of the F4 capacity when Power App starts to read data from SQL DB.

This number is not aligning with the performance summary of the Fabric database. The memory tab only shows mb not compute usage.