General Microsoft Fabric Billing Model
Microsoft Fabric uses a capacity-based pricing model.
Your bill will primarily consist of:
- Capacity Compute: Based on the CU consumption of all workloads running within your Fabric capacity.
- OneLake Storage: Based on the amount of data stored in OneLake. Transaction costs (reads, writes) to OneLake are generally included in the capacity compute.
- Optional Add-ons: Such as резервирование capacity for discounted rates.
Impact of Direct Lake vs. Direct Query on Billing
While direct case studies are lacking, we can infer the potential billing implications:
1. Capacity Compute (CU Consumption):
- Direct Lake:
- Queries against Direct Lake models are processed by the VertiPaq engine (the same in-memory engine used by Power BI Import mode).
- Since the data is directly read from OneLake in Parquet format and loaded into memory on demand for querying, the compute consumption is expected to be efficient and potentially lower compared to Direct Query for analytical workloads.
- The refresh operation for Direct Lake models is metadata-only, making it a low-cost operation in terms of compute.
- However, if a Direct Lake model falls back to Direct Query (e.g., due to unsupported features or row-level security on the SQL endpoint), the compute consumption would be similar to a standard Direct Query.
- Queries against Direct Lake models are processed by the VertiPaq engine (the same in-memory engine used by Power BI Import mode).
- Direct Query:
- DAX queries are translated into the query language of the underlying data source (e.g., T-SQL for Fabric Data Warehouse or SQL endpoint of Lakehouse) and executed on that source.
- The compute cost here depends heavily on the efficiency and scale of the underlying data source. If the source is not optimized for BI-style queries, it can lead to higher CU consumption as Fabric waits for the source to return results.
- Each query execution against the source will contribute to the overall capacity consumption.
- DAX queries are translated into the query language of the underlying data source (e.g., T-SQL for Fabric Data Warehouse or SQL endpoint of Lakehouse) and executed on that source.
2. OneLake Storage:
- Direct Lake: The underlying data resides in OneLake in Delta Parquet format. The storage cost will be based on the volume of data stored in OneLake. Direct Lake itself doesn't incur additional storage costs beyond the base OneLake storage.
- Direct Query: The data also resides in some form of storage (e.g., OneLake, Data Warehouse). Similar to Direct Lake, the storage cost is tied to the underlying data storage.
3. Specific Billing Line Items:
Without specific case studies, it's challenging to provide exact billing line items. However, when you analyze your Fabric capacity consumption in the Microsoft Fabric Capacity Metrics app, you would likely see:
- For Direct Lake: Operations related to "Semantic Model Queries" or similar, reflecting the CU consumption of the VertiPaq engine processing the queries. OneLake read operations might also be visible.
- For Direct Query: Operations related to the specific workload being queried (e.g., "Data Warehouse Query", "Lakehouse SQL Query"), indicating the CU consumption while Fabric interacts with that engine.
Key Considerations:
- Optimization of Underlying Sources: For Direct Query, ensure your Data Warehouse or Lakehouse SQL endpoint is well-optimized with appropriate indexing and partitioning to minimize query execution time and thus CU consumption.
- Data Volume and Complexity: Larger data volumes and more complex queries will generally consume more CUs regardless of the query mode. However, Direct Lake is designed to handle large volumes efficiently.
- Fallback to Direct Query: Be aware of scenarios where Direct Lake might fall back to Direct Query, as this could impact performance and potentially increase CU consumption.
- Monitoring: Regularly monitor your Fabric capacity consumption using the Metrics app to understand how different workloads and query types contribute to your bill. Filter by workload and operation type to get a better understanding.
In summary, while direct billing case studies for Direct Lake vs. Direct Query are not readily available, the expectation is that Direct Lake, being optimized for large-scale analytics on OneLake data, would generally lead to more efficient compute utilization for BI workloads compared to Direct Query against potentially less optimized data sources. Storage costs are primarily tied to the volume of data in OneLake, irrespective of the query mode used for consumption.
To get a clearer understanding of your specific billing, it's recommended to:
- Experiment with both Direct Lake and Direct Query scenarios with your data.
- Monitor the CU consumption in the Microsoft Fabric Capacity Metrics app for each scenario.
- Analyze the operation-level details to see how each query type contributes to your overall capacity usage.
- Review your Azure bill for the Fabric capacity to see the total CU consumption and storage costs.
This hands-on approach with your specific data and workloads will provide the most accurate insights into the billing implications of Direct Lake vs. Direct Query in your environment.
