OneLake costs simplified: lowering capacity utilization when accessing OneLake
We’re thrilled to share a major update and simplification to OneLake’s capacity utilization model that will make it even easier to manage Fabric capacity and scale your data workloads. We are reducing the consumption rate of OneLake transactions via proxy to match the rate for transactions via redirect. This means you no longer have to worry where you are accessing your OneLake data from (via proxy or redirect), they will consume your capacity at the same low rate.
This isn’t just a rate change—it reflects our continued investment in making OneLake the foundation for your entire data estate. We’ve designed OneLake from the ground up to be open and extensible, enabling you to connect to structured and unstructured data of any format. Thousands of customers have already adopted OneLake as their organization’s central, accessible location to access data from across their data estate. Aligning the consumption rates for proxy and redirect helps ensure that OneLake remains open, predictable, and ready to support any architecture, no matter what tools you are using in your estate.
To understand how this change impacts your day-to-day usage, let’s break down what it means in practical terms.
Optimizing your Fabric capacity spend
All your Fabric items—whether you’re working in a lakehouse, warehouse, or another data item—are prewired to store data in OneLake. Storage in OneLake is billed using a pay-as-you-go model based on the amount of data stored (per GB), like Azure Data Lake Storage (ADLS) or Amazon S3.
Requests to OneLake (e.g., read, write, or list) consume Fabric Capacity Units (CUs) from your existing Fabric capacity. OneLake supports two access paths: redirect and proxy. Applications will use one of these paths based on specific circumstances, some determined by the workload and others outside its control. To minimize the impact of this implementation detail, requests via proxy and redirect now share the same low consumption rate, comparable to ADLS, eliminating the need to worry about which path your workload takes.
Here’s a breakdown of the changes in proxy rates:
| Operation Type | Redirect CU rate | Previous Proxy CU rate | New Proxy CU Rate |
|---|---|---|---|
| Read (per 4 MB, per 10,000 ops) | 104 CU seconds | 306 CU seconds | 104 CU seconds |
| Write (per 4 MB, per 10,000 ops) | 1626 CU seconds | 2650 CU seconds | 1626 CU seconds |
| Iterative Read (per 10,000 ops) | 1626 CU seconds | 4798 CU seconds | 1626 CU seconds |
| Other Operations (per 10,000 ops) | 104 CU seconds | 306 CU seconds | 104 CU seconds |
The new consumption rate is now in effect in most regions, with full availability in the coming days.
Simplifying OneLake pricing based on your feedback
Our goal has always been to make OneLake as open and simple as possible, and pricing is a critical part of that. By aligning the consumption rates, we’re removing that complexity and making OneLake more predictable—regardless of your architecture or tools.
What’s next?
Whether you’re using Microsoft Fabric, Azure Databricks, Snowflake, or other tools, you can now connect to OneLake with confidence—knowing your costs are consistent and transparent. This update is part of our broader commitment to making OneLake the most open, performant, and cost-effective data lake for all your analytics needs.
For more information, check out the following resources:
