Fabric versus Databricks, purely on cost

A user asked on Reddit a question that comes up in almost every platform selection exercise: how does Microsoft Fabric compare to Azure Databricks if you look purely at cost? And is there a way to convert Fabric capacity pricing into the Databricks consumption model, so you can put them side by side fairly?

That second question is the interesting one, because it rests on an assumption that does not hold. Fabric is sold per capacity: you buy an F SKU with a fixed number of Capacity Units and those are continuously available to you, whether you use them or not. Azure Databricks bills per DBU consumed: if nothing runs, you pay nothing for that compute. One model reserves capacity, the other measures consumption. You cannot convert between them without first knowing what your workload looks like over time, and that is exactly what most comparisons skip.

The discussion accordingly moved away from the licensing question and shifted to where the real cost sits: operational overhead, platform maturity and the nature of the workload itself.

No consensus emerged from the discussion, and that in itself is the first signal.

One group of architects maintained that Azure Databricks remains the better choice for data engineering. Their argument deliberately went beyond compute cost. They pointed at maturity: Databricks has been running production workloads for years, while Fabric is still evolving rapidly. Missing functionality and operational workarounds cost engineering time, and that time never appears on the Azure invoice but very much shows up in total cost of ownership.

Another group disagreed and argued that Fabric often works out cheaper, particularly for organisations already running on Power BI and the wider Microsoft stack. Their criticism of the original question was sharp: comparing Fabric Capacity Units directly against Databricks Serverless compute is misleading, because the two pricing models fundamentally measure different things.

Several practitioners also shared concrete proof-of-concept experiences. One engineer reported that a Databricks Serverless workload processing CSV files into Delta tables finished considerably faster and cheaper than the same workload on a Fabric F2 capacity. Another described moving scheduled workloads from Fabric to Databricks, because scaling from F64 to F128 would have doubled monthly platform cost while the same jobs running as Databricks Jobs stayed substantially cheaper.

A final group thought the framing itself was wrong. Their proposal was not Fabric versus Databricks but Fabric and Databricks: keep data engineering and Spark workloads on Azure Databricks and use Microsoft Fabric for semantic models, reporting and Power BI. Each platform then does what it was built for.

These contributions are personal experiences and proof-of-concepts, not official guidance from Microsoft or Databricks. Treat the reported outcomes as signals from the field, not as benchmarks.

Microsoft's own documentation supports the discussion's main conclusion, and at the same time corrects the assumption underneath it.

To begin with, there is no official conversion formula between Fabric Capacity Units and Databricks DBUs, and Microsoft does not offer one. What Microsoft does offer is a measurement instrument: the capacity SKU gives you a fixed number of CUs shared across all Fabric workloads, and the Fabric Capacity Metrics app measures consumption using the same 30-second evaluation period the platform itself uses. The capacity planning guidance accordingly tells you to measure and pilot, not to convert up front. See https://learn.microsoft.com/fabric/enterprise/plan-capacity.

The F64 to F128 jump mentioned in the discussion is indeed a doubling: the SKU table runs from F2 with 2 CUs through F64 with 64 CUs to F128 with 128 CUs. Every step doubles both capacity and price. That is precisely why a capacity model feels expensive the moment you tip just over the edge, while a consumption model scales gradually.

Fabric absorbs peaks better than the discussion suggests, incidentally. Smoothing spreads the evaluation of compute out so a spike does not immediately cause throttling, and according to Microsoft smoothing does not affect execution time. On top of that, burstable capacity provides a scale factor per SKU: smaller SKUs such as F2 can burst up to 32 times, while F64 and F128 go up to 12 times. Microsoft explains that difference from usage pattern, since smaller SKUs are mostly used for dev, test and ad hoc work and carry lower average utilisation. See https://learn.microsoft.com/fabric/data-warehouse/burstable-capacity and https://learn.microsoft.com/fabric/data-warehouse/compute-capacity-smoothing-throttling.

The most important point, however, is that Microsoft not only shares the community's "combine both platforms" recommendation but ships official integration for it. Azure Databricks connects to Microsoft Fabric in two ways, and both surface Unity Catalog tables as a read-only mirrored catalog in Fabric, with no data movement. The Fabric-initiated route, where a workspace administrator picks Mirrored Azure Databricks catalog, is generally available. The Databricks-initiated route, where a catalog admin picks Publish to OneLake, is currently in public preview. See https://learn.microsoft.com/azure/databricks/partners/bi/fabric.

For the cost question the underlying mechanism matters. Mirroring uses shortcuts rather than replication when the source already stores its data in an open format that OneLake can read directly. Delta tables in Unity Catalog fall into that category, so they are referenced in place instead of copied. Microsoft states explicitly that shortcuts to mirrored data do not create another copy and do not add storage cost. See https://learn.microsoft.com/fabric/onelake/unify-data.

Running both platforms side by side therefore does not automatically mean paying for storage twice. That makes the hybrid approach from the discussion considerably more defensible financially than it first appears.

The question "which platform is cheaper" cannot be answered because a variable is missing: the utilisation of your workload.

Fabric capacity is a fixed cost. You pay for F64 whether you use 20 percent or 90 percent of it. That works in your favour as soon as you share that capacity across many workloads, because every additional pipeline, notebook or semantic model is marginally free as long as you stay within the capacity. It works against you the moment a single heavy batch pushes you just over the line, because then you buy a doubling to absorb a peak lasting a few hours.

Databricks consumption is a variable cost. A job that runs for twenty minutes costs twenty minutes. That works in your favour for concentrated, periodic workloads and against you for a continuously running platform where the sum of all those minutes exceeds a reserved capacity.

On top of that, the compute choice within Databricks itself already makes a large difference. All-purpose compute on Premium sits at 0.55 DBCU per hour, Jobs compute on the same tier at 0.30 DBCU per hour. Moving scheduled workloads from an all-purpose cluster to Lakeflow Jobs therefore saves roughly 45 percent on the DBU component without changing a line of code. That explains why several participants came out cheaper after a migration: they were not only comparing platforms, they were simultaneously switching to a cheaper compute type.

Two things to keep in mind during that calculation. Photon speeds up queries but increases the number of DBUs per hour, so the gain comes from shorter runtime rather than a lower rate. And a DBCU prepurchase covers only the DBU component: the underlying virtual machines, storage and networking appear separately on your Azure invoice. Anyone setting DBUs against CUs alone is comparing part of one bill against the whole of the other.

The point about operational overhead deserves serious treatment, even though it comes from a forum. Engineering time is the most expensive line in almost any data platform. A workaround costing an engineer two days a month exceeds, in most organisations, the difference between an F32 and an F64. That is not an argument for or against either platform, it is an argument for putting that time explicitly into the comparison instead of only laying the Azure invoices side by side.

"The question is not which platform is cheaper, but which workload belongs where."

Practically, that means the following. Put heavy, scheduled transformations and Spark work on Azure Databricks with Lakeflow Jobs, where you pay per minute consumed. Put semantic models, reporting and Power BI on Microsoft Fabric, where the capacity is standing anyway and where Direct Lake and the rest of the stack reinforce each other. Connect the two through the mirrored Unity Catalog integration, so the same Delta tables are visible on both sides without a second copy. And measure afterwards, because every estimate up front remains an estimate.