- Fabric is billed as capacity for every hour it runs, and all workloads in the workspace share it. Databricks bills DBUs for running compute, and for classic compute Azure also bills the virtual machines.
- Power BI reads data from Fabric in Direct Lake mode straight from OneLake. It connects to Databricks with Import or DirectQuery through a SQL warehouse, or through a Unity Catalog catalog mirrored into Fabric.
- Each platform's data is reachable from the other: Fabric mirrors Unity Catalog through shortcuts, and Databricks reads from and writes to OneLake through an ABFS path.
Contents 8 sections
- 01Microsoft Fabric vs Databricks, how do they differ?
- 02Fabric vs Databricks, cost
- 03Who runs the platform
- 04Power BI and Direct Lake
- 05Delta, OneLake shortcuts and Unity Catalog
- 06Code and orchestration
- 07Where does Snowflake fit?
- 08FAQ
Microsoft Fabric vs Databricks, how do they differ?
Fabric is Microsoft's SaaS, and Power BI is part of it. Lakehouse, warehouse, pipeline, notebook and semantic model all run on one capacity, the data sits in OneLake and the capacity runs in one Azure region (Fabric architecture). Databricks is a data platform built around Spark. The control plane runs in the Databricks account, classic compute in your Azure subscription, and serverless compute in a compute plane that Databricks manages (Azure Databricks architecture).
Fabric and Databricks side by side
| Question | Microsoft Fabric | Databricks |
|---|---|---|
| What you pay for | F SKU capacity per hour of running, or a one-year reservation | DBUs by compute type, for classic compute also virtual machines, disks and network in Azure |
| Where compute runs | on a Fabric capacity that Microsoft manages | classic compute in your subscription, serverless in the Databricks account |
| Spark | starter pool with no setup, custom pools optional | clusters governed by the policies you set, or serverless |
| Power BI | Direct Lake over OneLake | Import or DirectQuery through a SQL warehouse, Direct Lake through mirroring into Fabric |
| Data format | Delta in OneLake, Iceberg through metadata virtualization | Delta and Iceberg tables in Unity Catalog |
| Catalog and permissions | OneLake catalog, OneLake security, Microsoft Purview | Unity Catalog |
| Cloud | Azure regions | Azure, AWS, Google Cloud |
| No-code ingestion | Copy job, pipeline, Dataflow Gen2 | Lakeflow Connect managed connectors |
| Spending cap | capacity size, above it smoothing and throttling, optionally capacity overage | budgets with email alerts, compute policies with a DBU-per-hour limit |
Fabric vs Databricks, cost
With Fabric you pay for capacity with fixed performance, for every hour it runs, even when it computes nothing. With Databricks you pay for DBUs by how long compute runs, and compute that isn't running consumes no DBUs.
You buy Fabric as fixed performance. F2 costs €244 a month, F64 €7,812 a month, and a one-year reservation is 41% cheaper. You pay for the capacity for every hour it runs, even when it computes nothing, and pausing it saves money (pausing capacity). When workloads overload the capacity, Fabric spreads the consumption over time, and once the headroom is used up it delays new operations, then rejects them (throttling). Instead of throttling, capacity overage pays for the overload, at three times the pay-as-you-go rate, up to a daily threshold that the capacity admin sets and that isn't a hard cap (capacity overage).
From F64 up, report readers with the Viewer role need only a free license, below F64 every reader needs Power BI Pro or PPU (Fabric licenses). OneLake storage is paid separately, €0.02 per GB a month, and reads and writes on it consume capacity (OneLake consumption).
You pay for Databricks in DBUs, a unit of compute billed by run time. Each compute type has its own rate: in Azure Databricks Premium a DBU costs €0.26 for jobs, €0.48 for all-purpose clusters and €0.80 for serverless SQL warehouse. For classic compute Azure bills virtual machines, disks and network on top of the DBUs, for serverless compute the virtual machines are included in the DBU price (Azure Databricks costs). Prepaid DBCUs for one or three years give a discount on DBUs, while virtual machines and storage are still paid separately (Azure Databricks prepurchase).
Compute that isn't running consumes no DBUs. A SQL warehouse stops after the idle time set in Auto Stop, 10 minutes by default for serverless, and keeps billing until then (SQL warehouse settings). Budgets in the Databricks account track monthly spend and send email alerts, with a delay of up to 24 hours, and they can stop usage only for Unity Gateway (budgets). A compute policy caps the spend of a single cluster with a maximum of DBUs per hour (compute policies).
Prices checked October 11, 2026 against Microsoft's price list, in euros excl. VAT, for Azure region Sweden Central. They may differ in rare cases by region, agreement and partner.
Who runs the platform
In Fabric, a notebook starts a Spark session on a starter pool that Microsoft keeps prewarmed. Without custom libraries and session settings it typically starts in 5 to 10 seconds, custom pools with a different node size take longer to start (Spark in Fabric). You buy the capacity in an Azure subscription, and administration revolves around workspaces, permissions and capacity size (buying capacity).
In Azure Databricks, classic compute runs in a virtual network in your subscription. The workspace admin limits cluster size, auto-termination, virtual machine types and maximum DBUs per hour with compute policies. Databricks manages serverless SQL warehouse, including scaling, patches and updates (SQL warehouse). Unity Catalog is enabled automatically in workspaces created after November 9, 2023 (Unity Catalog).
Power BI and Direct Lake
A semantic model in Direct Lake mode reads Delta tables straight from OneLake, with no import (Direct Lake). Two paths lead to data in Azure Databricks.
Azure Databricks connector. Power BI connects to a SQL warehouse or a cluster with Import or DirectQuery. You can also publish a semantic model to Power BI straight from the catalog in Databricks. The Power BI task in Lakeflow Jobs publishes it automatically (Power BI with Azure Databricks). In DirectQuery every report query runs on the SQL warehouse, which starts on its own for the query and bills DBUs until it stops after idling.
Mirrored catalog in Fabric. Fabric mirrors only the structure of the Unity Catalog catalog, reads the data through shortcuts without a copy, and you can build Direct Lake on the mirrored item (mirroring Unity Catalog). According to the Databricks documentation, Fabric reads with the identity of whoever set up the connection, so Unity Catalog permissions don't apply to Fabric users. Mirroring doesn't support views, tables with row filters or column masks, or any format other than Delta, and it needs a running Fabric capacity (reading Unity Catalog from Fabric).
Direct Lake performance depends on the layout of the Delta tables: V-Order, the number of files and the row group size (Direct Lake performance). According to Microsoft, V-Order is a write optimization specific to Fabric (Delta Lake in Fabric). Even in Fabric it isn't applied on its own: a new workspace writes from Spark with the writeHeavy profile, with V-Order off, and the readHeavyForPBI profile turns it on (write profiles). How table layout changes Direct Lake performance, with measurements, is covered in the article on Direct Lake Performance Based on Delta Layout.
Delta, OneLake shortcuts and Unity Catalog
Both platforms store tables as Delta on top of Parquet. OneLake also uses metadata virtualization to read Iceberg tables as Delta and to expose Delta tables to Iceberg readers (Iceberg in OneLake). With a shortcut, Fabric points without a copy to data in another workspace, in ADLS, Amazon S3, Google Cloud Storage and other storage (OneLake).
Databricks reads from and writes to OneLake through an ABFS path, with Spark on classic clusters and with the deltalake library on serverless compute (OneLake and Azure Databricks). In Beta, Unity Catalog can use OneLake as an external location for managed tables (OneLake as an external location).
Unity Catalog in Databricks manages permissions, lineage, audit and data discovery. In Fabric the same work is split between the OneLake catalog, with lineage, domains and item endorsement, and Microsoft Purview for sensitivity labels, DLP and audit (Purview and Fabric).
Code and orchestration
Both platforms run Apache Spark, so PySpark and Spark SQL over Delta tables run on both. The tooling around them differs: the notebook helper functions are dbutils in Databricks and notebookutils in Fabric (NotebookUtils). Declarative pipelines, formerly Delta Live Tables, are now called Lakeflow pipelines in Databricks (what happened to DLT). In Databricks, Lakeflow Jobs orchestrates jobs, in Fabric a pipeline does.
Where does Snowflake fit?
Fabric can mirror Snowflake: it replicates managed tables into OneLake and exposes Iceberg tables as Delta through shortcuts (Snowflake mirroring). Snowflake on Azure can also write Iceberg tables to OneLake and read Delta tables from OneLake as Iceberg (Snowflake and Iceberg in OneLake). Power BI connects to Snowflake with Import or DirectQuery, and DirectQuery in the Power BI service needs no gateway (DirectQuery in Power BI).
FAQ
Is Fabric cheaper than Databricks?
It depends on your workload, because the two platforms are billed differently. With Fabric you pay for capacity the whole time it runs, regardless of load. With Databricks you pay for the DBUs of running compute, and for classic compute also for the virtual machines. You'll find both products in the Azure pricing calculator.
Can Databricks be used with Power BI?
Yes. Both Power BI Desktop and the Power BI service connect to a SQL warehouse or a cluster in Azure Databricks with Import or DirectQuery. Databricks can also publish a semantic model to Power BI itself. The second path goes through a mirrored catalog in Fabric, with a model in Direct Lake mode on top of it.
Can we have both Fabric and Databricks?
Yes. Azure Databricks connects to Fabric in two ways: you publish the catalog from Databricks to Fabric, currently in Public Preview, or you mirror it from Fabric. In both cases the tables in Fabric are read-only and writes go through Databricks (Fabric with Azure Databricks). In the other direction, Databricks reads from and writes to OneLake. You pay for both platforms, and mirroring needs a running Fabric capacity.
Do we have to rewrite our Databricks code for Fabric?
PySpark and Spark SQL code over Delta tables runs on both platforms. What needs rewriting are the parts that rely on Databricks tooling: dbutils calls and Lakeflow pipelines, formerly Delta Live Tables. Orchestration in Lakeflow Jobs maps to a pipeline in Fabric.
Where do you stand?
Implementing Fabric
€2,100first step, Environment and Cost Audit, excl. VAT
We build a data platform at your company, on Fabric, on Azure or on Databricks, depending on what you already have and who will run it. It runs in your tenant and works without us too.
