Power Apps integration with Fabric

[BharathKumarS]

Hi All,

Should one map the backend of Power Apps to a Fabric SQL database? 

The Power apps is heavily used by more than 50 users with ~100-150 data entries per hour.

And the fabric capacity is a shared one meaning there are other data ingestions job and power bi reports being utilized via the same capacity.

So is it ideal to have a heavy transactional system relying on a shared Fabric capacity?

Also based on the MSFT doc as well, it is not recommened.

What is Fabric Apps (Preview)? - Microsoft Fabric | Microsoft Learn

[v-menakakota]

Hi @BharathKumarS ,
Thanks for reaching out to the Microsoft fabric community forum. 

I would also take a moment to thank @svenchio   , for actively participating in the community forum and for the solutions you’ve been sharing in the community forum. Your contributions make a real difference. 
I hope the above details help you fix the issue. If you still have any questions or need more help, feel free to reach out. We’re always here to support you.

Best Regards, 
Community Support Team

[BharathKumarS]

Hi All,

Should one map the backend of Power Apps to a Fabric SQL database? 

The Power apps is heavily used by more than 50 users with ~100-150 data entries per hour.

And the fabric capacity is a shared one meaning there are other data ingestions job and power bi reports being utilized via the same capacity.

So is it ideal to have a heavy transactional system relying on a shared Fabric capacity?

Also based on the MSFT doc as well, it is not recommened.

What is Fabric Apps (Preview)? - Microsoft Fabric | Microsoft Learn

[deborshi_nag]

Hello @BharathKumarS 

Fabric SQL endpoints are not intended for high-frequency OLTP transactional workloads, particularly when running on shared capacity with mixed workloads. This can result in unpredictable latency, throttling, or reduced performance. Therefore, I would not suggest using a Fabric SQL database for this purpose.

For transactional workloads, consider using Azure SQL Database, Dataverse, or SQL Server instead.

[svenchio · Accepted solution]

Hi @BharathKumarS  , so, I would answer your question first and offer a few additional notes next ... 

#1. "is it ideal to have a heavy transactional system relying on a shared Fabric capacity" - The ansswer is NO, it is far from ideal! Based on your description, your "heavy transactional system" serves many users, so, if for any reason your fabric capacity units are exacusted by any of the other processed (e.g. a very big data ingestions job!) then, all your workspaces attached to that capacity will stop working, including any Fabric SQL databases within, the result, is that you will have  50 very angry users! 😅 

A much better approach is to have a separate capacity for your heavy transactional system 🤞 , start with a low SKU (e.g. F2) and monitor the consumption, and increate your capacity until you reach the optimal ratio of capacity vs cost. 

If you would like to continue the conversation, let me know! A  thumbs-up woyld be nice if you find my recommendations useful, or event better to mark as a solution. All the very best.