Forum Discussion
Power Apps integration with Fabric
- 3 months ago
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.
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_nag3 months agoSuper User
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.