Every few weeks somebody on Azure asks us to settle it. Fabric or Databricks. The framing has quietly gone out of date, and Microsoft's own documentation is where you notice it first, because the page describing Databricks in Fabric ends a paragraph with a sentence no competitor writes about a rival: "Azure Databricks and Fabric are better together."
That isn't marketing generosity. It's what the engineering shipped.
What both sides actually built
Fabric can mirror an Azure Databricks Unity Catalog. Microsoft is unusually precise about what that means. The mirror involves "no data movement or data replication", and "only the Azure Databricks catalog structure is mirrored to Fabric and the underlying catalog data is accessed through shortcuts." The tables arrive in OneLake as a read-only item with its own SQL analytics endpoint, and Power BI builds a Direct Lake model straight on top of them.
Databricks built the return path. Unity Catalog federates a Fabric Lakehouse or Warehouse as a foreign catalog, so somebody in a Databricks notebook queries Fabric data with ordinary three-part names, under Unity Catalog grants, with nothing copied.
So an estate on Azure doesn't have to pick a side. It has to decide which platform holds the tables, which is a smaller and much more answerable question.
The two directions aren't equally finished
Here's the part the comparison posts skip, and it decides more than any feature table will.
Databricks into Fabric is the mature direction. It's generally available, it moves no data, and the thing most teams actually want out of Fabric, which is a fast Power BI model over governed data, works against it.
Fabric into Databricks is real and thinner. The documentation is blunt about the ceiling: "Read-only access: Only SELECT queries are supported. Write operations are not available." Only Lakehouse and Warehouse items federate. Complex datatypes, meaning the arrays, maps and structs that any real lakehouse table is full of, aren't supported. It also needs a Fabric administrator to switch on three separate tenant settings before a single query runs, which is a conversation rather than a configuration in most organisations.
Databricks writing directly into OneLake, the capability that would make the two genuinely symmetric, hasn't landed. Both companies have said publicly that they're working on it.
Treat that asymmetry as a direction of travel and not a scoreboard. It says the composition both vendors have finished is Databricks holding the data and Fabric reading it. The opposite arrangement is possible today and it is visibly younger.
Both directions drop the same things
Anyone designing around either path should know this first, because the gap is nearly identical on both sides and neither vendor leads with it.
Fabric's mirror won't show you materialized views or streaming tables, and it hides external tables that aren't Delta. Databricks' federation won't show you views or materialized views either, and it stops at complex datatypes.
Plain tables cross the boundary. Anything derived stays home.
That has a real design consequence. If your gold layer is a set of views over a silver layer, the views are exactly what the other platform can't see, and you'll be materialising them as tables to get them across. Better to learn that in a design session than in week three of a build.
The number that decides more than the architecture
Fabric capacity is bought as an F SKU, billed per second with a one-minute minimum and no commitment, or reserved yearly for less. Underneath that flexibility sits one threshold that reorganises the entire business case.
On F64 or larger, a user with a free licence and a viewer role can read Power BI content. Below F64, every single person who opens a report needs a Pro or Premium Per User licence of their own.
Work out where your organisation sits against that line before comparing anything technical, because it moves the arithmetic by more than any engine benchmark will. An organisation with four hundred report readers and an F32 is paying four hundred per-user licences. The same organisation on F64 pays for the capacity and nothing per reader. Price it in your own region, since F SKU pricing is regional and the reserved rate differs from the pay-as-you-go one.
A team that did the comparison properly published their numbers on r/MicrosoftFabric. They run Azure Databricks, evaluated Fabric for more than six months, and simulated their production ETL on both while following each platform's own best practices. "Just looking at the hard costs, DB was roughly 40% cheaper even with reservation discounting in Fabric. 40% is just isolated to the CUs emitted in Fabric - it should really be more like 60% if you factor in the cost of the capacity running 24/7."
The mechanism behind that number is more useful than the number. Capacity is the thing you buy, and it runs whether anybody is using it or not. When the same team added ad hoc analytical queries alongside the ETL they throttled the capacity, had to upsize, and the Fabric cost rose again. Ephemeral jobs that start and stop do not have that shape, and a shared capacity carrying mixed load is where the two pricing models genuinely diverge.
Read that with its date on it. The comment is a year old, the account has since been deleted, and Fabric has shipped a great deal in the meantime. It is evidence about how the capacity model behaves under mixed load, and it is not a current price comparison.
People tend to feel all this as complexity long before they feel it as cost. One practitioner put it plainly on Hacker News: "You should see how Microsoft does the PowerBI/ Fabric billing. Gotta get premium capacity and licenses and regular capacity and it's so bad."
Sentiment about the product has been rough in places too. Another commenter, writing in late 2025, was blunter: "Microsoft has Fabric now, but the reviews have been terrible (my experience included)." That's one person's experience, from a year that saw a great deal of Fabric ship, and we've since watched teams run perfectly happy Fabric estates. Worth reading as a warning about early adoption rather than a verdict on the product.
When you should just use Fabric
We migrate estates onto Databricks for a living, so treat what follows as the part we have an incentive to leave out.
Somebody who runs both platforms drew the line about as well as it can be drawn. "If you're a small company that doesn't have strict security concerns or a BI team that was doing ETL inside of Power BI and want to shift the low code ETL left with dataflow Gen 2, then Fabric was built for you." Their BI analysts love Dataflow Gen 2. Their data engineers tested Fabric, stayed on Databricks, and got Fabric approved anyway by telling IT it was "just Power BI", which is the most honest sentence about enterprise procurement anybody wrote that year.
If your analytics is Power BI, your data is Dataverse and a handful of Azure sources, and you already hold F64 capacity, Fabric is very likely the right answer on its own. Adding Databricks underneath gives you a second platform to staff, and the governance benefit is real but smaller than the operational cost until the estate grows past what Fabric handles comfortably.
If you have no data engineering capacity and no plan to build any, don't buy a platform that assumes it. A managed experience somebody can actually run beats an architecture that needs a team you haven't hired.
And if the only thing pushing you is that Export to Data Lake stops on 30 November, the smallest honest move is to keep the export shape you have and decide about the platform in your own time. We wrote about that deadline separately, including why Synapse itself is not the thing that's ending.
The strongest argument against all of this
A Fabric practitioner put the objection to this whole article in one line: "Rarely will you want both in a greenfield environment."
That is correct, and it deserves saying loudly. Starting from nothing, running two platforms means two bills, two skill sets and two governance models to keep in step, and the composition described above is overhead somebody chose for no reason. Pick one. The same commenter's advice to run a full technical evaluation per scenario is exactly right for a greenfield build.
Almost nobody reading this is greenfield. The estates we get called into already have Databricks somewhere, or Power BI everywhere, and usually both, bought by different teams in different years. There the choice was made years ago by accident, and the live question is whether the two things a company already owns can be made to work together instead of one of them being ripped out. That question has a supported answer now, and a year ago it did not.
What a good decision looks like now
Stop asking which platform is better and ask which one owns which layer.
Name the workloads. Separate the Power BI reporting from the transformation that runs for hours, from the machine learning, from the applications you want to build on this data next year. For each one, ask which platform it would sit on if you were starting today, and then check whether the interop carries it across the boundary. Plain Delta tables will. Your view layer won't.
Most Azure estates that do that exercise land somewhere unglamorous and correct. Databricks holds the tables and the governance, Fabric and Power BI serve the reporting, the mirror connects them, and nobody migrates anything twice. That answer is available today, it's supported by both vendors in writing, and it costs considerably less than picking a winner.
Our Synapse readiness sprint is two weeks and inventories what an Azure estate actually contains, because dedicated SQL pools, serverless, Spark and the Data Factory pipelines around them don't convert as one thing. If the finding is that Fabric alone serves you and we shouldn't build anything, that's a finding, and two weeks is a cheap way to get it.
Sources
Checked on 8 September 2026:
- Mirrored catalog from Azure Databricks, Microsoft, for the no-copy behaviour, Direct Lake support and what the mirror hides
- Enable OneLake catalog federation, Microsoft and Databricks, for the read-only ceiling and the federation limitations
- Understand Microsoft Fabric licenses and capacity, Microsoft, for the F SKU table and the F64 viewer rule
- Expanding support for OneLake in Unity Catalog, Databricks, for the bidirectional roadmap
- Practitioner comments quoted verbatim from Hacker News, on billing and on early experience
- Practitioner comments quoted verbatim from r/MicrosoftFabric, "Fabric vs Databricks", on the six-month cost evaluation, on who each platform was built for, and on greenfield estates. Those comments are about a year old, and the text says so where it matters.