Forum Discussion

fabricpribeiro's avatar
fabricpribeiro
Icon for Post Patron rankPost Patron
9 months ago
Solved

Fabric Capacities

Dears,

 

I was told to request to infrastructure team some fabric capacities

 

Our setup, per environment (dev, Test, Prod)  :

 

Exemple for Dev :

 

1 workspace in RAW which holds :

 

1.1 - one LH generated by dataverse direct Fabric link

1.2 - one DWH which will hold a Fabric SQL MI Mirroring

1.3 - one LH to hold Data factory Fabric CDC from a SQL Server 2008 on-prem DB

 

1 workspace in Bronze which holds :

 

1.1 - one LH Which will have shortcuts to RAW tables from above RAW Items (DWH does not support shortcuts , hence probably one of the other items in RAW will have views pointing to it so that we can then use shortcuts). On top of it we will create tables via notebooks to persist the ables in Bronze but with the schemas which we want 

 

1 workspace in Silver which holds :

 

one LH Which will have shortcuts to Bronze tables from above Items and then notebooks which will persist the tables in this layers and do some transformations on them (cleasing, de-dup, etc...)

 

Note : As you noticed, we did not spoke about gold layer as that one will be consider only in the future and will be domain based, hence with different necessities. for the time being we are only consider capacities till silver

 

Normally, to request capacities, we have in consideration factors like : Data Volume, Number of Concurrent Users, Refresh Frequency, etc...

 

But at this stage we don't know very well our sources, hence I was told to work with this assumptions:

 

1 - We will have more or less 150 users 

2 - We are not sure about concorrency, lets state 10 concurrent users

3 - If possible use reservations to reserve capacities so that it gets cheaper

4 - The data in Dataverse is more or less 50 Million Rowns in total,  with 2 or 3 tables with 200 columns, the rest will have much less 

 

Please find below my questions:

 

1 - If I have a LH in my own RAW ws, and someone creates shortcuts of it to their LH in their own WS. That is the capacity that will be used when they query this shortcuts , for example via SQL Endpoint in their LH, will it be our capacity or their capacity? I guess its ours , right? because they are just using the shortcuts, the real tables are on our side. 

 

2 - If I reserve a capacity, say with F8 , for 6 months or 1 year, and I want, after 3 months to upgrade it to F16, will I pay only the difference ? meaning F8? or do I have to pay the entire F16 as if I had not already reserved F8 ?

 

3 - How are you reserving your capacities? for 1 year or more? What do yiou suggest as approach?

 

4- To start with, I will have only one capacity for Dev, one for Test and one for Prod. Prod will soon have, at least, two capacities (one till silver) when I start to build Gold layer, one for Gold. 

 

But for the time being , it will be only one capacity per environment.

 

I was thinking in F4 for Dev, F8 for Test and F8 for Prod. What do you think ? And shall we reserve them for how long?

 

Thanks, 

 

Pedro 

 

P.S - In Raw, we will be doing Dataverse Direct Link to Fabric and SQL MI Mirroring and SQL Server on Prem CDC. At least the first two are near realtime, but then, between layers (bronze, silver and gold) information will be moved once a day, not more)

 

 

 

  

 

 

  • Hello @fabricpribeiro, thank you for outlining your proposed environment setup so clearly. I will address your questions in short and provide relevant references where possible.

     

    1)

    If another user creates a shortcut to your Lakehouse within their own workspace, which operates under a separate capacity, the billing will apply to their capacity, not yours. As detailed in the Fabric documentation, the consumer’s capacity is charged when using shortcuts. Please see the Microsoft documentation for further information.

    Use OneLake shortcuts to access data across capacities: Even when the producing capacity is paused!…

     

    2)

    With Fabric capacity reservations, you receive a discount that corresponds to the reserved capacity—currently around 41% for a one-year reservation. You are permitted to exchange or upgrade to a higher capacity, such as the F16 you mentioned. Further details are available here:

    Save costs with Microsoft Fabric Capacity reservations - Microsoft Cost Management | Microsoft Learn

     

    3)

    I recommend reserving for one year, but it may be sensible to begin with PAYG to monitor your actual CU usage over the first three months before committing. Please ensure you pause compute resources for PAYG when not in use, either manually or via automation scripts.

     

    4)

    Based on your description, an F4 for Development should suffice for engineering and CICD purposes, while F8 is appropriate for QA with concurrent users. For production, you might consider reserving F8 initially and upgrading to F16 if necessary, particularly as you have RAW with Dataverse Direct Link.

     

2 Replies

  • I would consider F16 for Test and Prod. Usually, test and prod deal with higher volumes of data and you don't want to run out of capacity in those instances.
    F4 for Dev is a good choice.

  • Hello @fabricpribeiro, thank you for outlining your proposed environment setup so clearly. I will address your questions in short and provide relevant references where possible.

     

    1)

    If another user creates a shortcut to your Lakehouse within their own workspace, which operates under a separate capacity, the billing will apply to their capacity, not yours. As detailed in the Fabric documentation, the consumer’s capacity is charged when using shortcuts. Please see the Microsoft documentation for further information.

    Use OneLake shortcuts to access data across capacities: Even when the producing capacity is paused!…

     

    2)

    With Fabric capacity reservations, you receive a discount that corresponds to the reserved capacity—currently around 41% for a one-year reservation. You are permitted to exchange or upgrade to a higher capacity, such as the F16 you mentioned. Further details are available here:

    Save costs with Microsoft Fabric Capacity reservations - Microsoft Cost Management | Microsoft Learn

     

    3)

    I recommend reserving for one year, but it may be sensible to begin with PAYG to monitor your actual CU usage over the first three months before committing. Please ensure you pause compute resources for PAYG when not in use, either manually or via automation scripts.

     

    4)

    Based on your description, an F4 for Development should suffice for engineering and CICD purposes, while F8 is appropriate for QA with concurrent users. For production, you might consider reserving F8 initially and upgrading to F16 if necessary, particularly as you have RAW with Dataverse Direct Link.