Fabric Capacity and OneLake Consumption

You only need one capacity to drive all your Microsoft Fabric experiences, including Microsoft OneLake. Keep reading if you want a detailed example of how OneLake consumes storage and compute.

Overview

OneLake comes automatically with every Fabric tenant and is designed to be the single place for all your analytics data. All the Fabric data items are prewired to store data in OneLake. For example, when you store data in a lakehouse or warehouse, your data is natively stored in OneLake.
With OneLake, you pay for the data stored, similar to services like Azure Data Lake Storage (ADLS) Gen2 or Amazon S3. However, unlike other services, OneLake doesn't include a separate charge for transactions (for example, reads, writes) to your data. Instead, transactions consume from existing Fabric capacity that is also used to run your other Fabric experiences. For information about pricing, which is comparable to ADLS Gen2, see Fabric pricing. To illustrate, let’s walk through an example. Let’s say you purchase an F2 SKU with 2 Capacity Units (CU) every second. Let’s name this Capacity1. You then create Workspace1 and upload a 450 MB file to a lakehouse using the Fabric web portal. This action consumes both OneLake storage and OneLake transactions. Now, let’s dive into each of these dimensions.

OneLake Storage

Since OneLake storage operates on a pay-as-you-go model, a separate charge for "OneLake Storage" appears in your bill corresponding to the 450 MB of data stored. If you're a capacity admin, you can view your storage consumption in the Fabric Capacity Metrics app. Open the Storage tab and choose Experience as "lake" to see the cost of OneLake storage. If you have multiple workspaces in the capacity, you can see the storage per workspace.

Diagram showing how OneLake storage is viewed in Fabric Metrics app.

In the below image, you have two columns called billable storage and current Storage. Billable storage shows the cumulative data over the month. Because the total charge for data stored isn't taken on one day in the month, but on a pro-rated basis throughout the month. You can estimate the monthly price as the billable storage (GB) multiplied by the price per Gb per month. So, if you stored 1 TB of data on day 1, you would see on day one the 1 TB / 30 days = 33 GB. Then every day would add 33 GB until the last day when you see 1 TB in the billable storage. Also remember that OneLake soft delete protects individual files from accidental deletion by retaining files for a default retention period before it's permanently deleted. All soft-deleted data is billed at the same rate as active data.

Diagram shows billable and current storage difference.

OneLake Compute

Requests to OneLake, such as reading, writing, or listing, consumes your Fabric capacity. OneLake follows similar mapping of APIs to operations like ADLS. The CU consumption per each type of operation can be viewed in the Fabric Capacity Metrics app. In our example, the file upload resulted in a write transaction that consumed 127.46 CU Seconds of Fabric Capacity. This consumption is reported as "OneLake Write via Proxy" in the operation name in Capacity Metrics App. Now let’s read this data using a Fabric notebook. You consume 1.39 CU Seconds of read transactions. This consumption is reported as "OneLake Read via Redirect" in the Metrics app. Refer to the OneLake consumption page to learn more about how each type of operation consumes capacity units.

Diagram showing how OneLake compute is viewed in Fabric Metrics app.

To understand more about the various terminologies on the metrics app, refer to Understand the metrics app compute page - Microsoft Fabric.

You may be wondering, how do shortcuts affect my OneLake usage? In the above scenario, both storage and compute are billed to Capacity1. Now, let’s say you have a second capacity Capacity2, that contains Workspace2. You create a lakehouse and create a shortcut to the parquet file you uploaded in workspace1. You create a notebook to query the parquet file. As Capacity2 accesses the data, the compute or transaction cost for this read operation consumes CU from Capacity2. The storage continues to be billed to Capacity1.

Diagram showing how shortcut billing is done per capacity.

What if you pause the capacity? Let’s say Capacity2 is paused and Capacity1 isn't paused. When Capacity2 is paused, you can’t read the data using the shortcut from Workspace2 in Capacity2, however, you can access the data directly in Workspace1. Now, if Capacity1 is paused and Capacity2 is resumed, you can't read the data using Workspace1 in Capacity1. However, you're able to read data using the shortcut that was already created in Workspace2 in Capacity2. In both these cases, as the data is still stored in Capacity1, the data stored is billed to Capacity1.

At any point, if your CU consumption exceeds your capacity limit, your capacity is throttled. Transactions may be rejected or delayed for a given window of time when capacity is throttled. Here's more about throttling.

We encourage you to start Fabric’s 60-day free trial to explore OneLake and other Fabric features. For more questions, please refer to our Fabric forum.