Forum Discussion

SamyAbdul's avatar
SamyAbdul
Frequent Visitor
12 days ago
Solved

Fabric costs

Hi experts , we have in process of identifying cost reduction for our Fabric development. And our team member suggesting that for data ingestion that is API based, instead of notebooks using Logic ap...
data engineering
data pipeline
lakehouse
Notebook
  • tayloramy's avatar
    tayloramy
    12 days ago

    Hi SamyAbdul​ 

    Logic Apps and Azure functions cost depends on usage, you pay every time they run. 

    Fabric notebooks on the other hand use your Fabric capacity, so as long as you have the headroom in your fabric capacity notebooks don't cost anything extra. 

    The only way this would make sense is if by moving to logic apps and functions, you would reduce your Fabric capacity to a lower level, and the usage of the logic apps and functions would cost less than what you saved by reducing the fabric capacity. 

ShivekMaharaj's avatar
ShivekMaharaj
Icon for Community Champion rankCommunity Champion
12 days ago

Hi SamyAbdul​,

I would be careful with the statement that notebooks are effectively “free” once you already have Fabric capacity.

Fabric notebooks still consume Capacity Units, and active Spark sessions can continue consuming capacity while they are running.

So I would not decide this based only on whether Logic Apps/Azure Functions have separate usage charges.

The real comparison is:

Fabric notebook ingestion
-> consumes Fabric CU

Logic Apps / Azure Functions
-> external Azure cost
-> may reduce Fabric CU usage

The important question is whether moving the workload out of Fabric reduces your capacity requirement enough to offset the added Azure cost and operational complexity.

Before changing the architecture, I would use the Fabric Capacity Metrics app to identify how much CU your notebooks are actually consuming.

Microsoft also recommends using the metrics app to identify high-consumption Spark workloads and throttling before resizing or redesigning workloads.

For API-based ingestion, I would generally choose based on workload characteristics:

  • simple/lightweight API calls, orchestration, webhooks -> Logic Apps / Functions can be a good fit
  • larger transformations, joins, Spark processing, medallion transformations -> Fabric notebooks are usually more natural
  • mixed workload -> external function for extraction, Fabric for transformation can also work well


So I would not move everything to Logic Apps or Functions purely for cost reasons.

I would first measure:

current notebook CU consumption
-> estimate reduced Fabric capacity requirement
-> estimate Logic App / Function execution cost
-> compare both options

That will give you a much more reliable answer than assuming one platform is automatically cheaper.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.