Databricks vs Microsoft Fabric: a decision guide

Databricks vs Microsoft Fabric comes down to who consumes the data. If most of it ends up in Power BI and your team thinks in SQL, Fabric is usually the faster and simpler choice. If your hard problems are engineering, streaming, machine learning or more than one cloud, Databricks is the stronger platform.

For many Microsoft-heavy organisations the honest answer is both. Azure Databricks does the heavy engineering. Fabric and Power BI serve the business. That works, but only if you design the seam between them on purpose.

In the manufacturing and defence programmes I've worked on, the decision rarely turns on feature lists. It turns on cost model, skills, security boundaries and where the data is allowed to live.

Both are lakehouses on open table formats. They differ in who owns the storage and how you pay for compute.

Microsoft Fabric is a SaaS platform. Everything lands in OneLake, one logical lake per tenant, with tables stored in Delta format. Lakehouse, warehouse, pipelines, Real-Time Intelligence and Power BI all draw on one shared capacity. Shortcuts point at data in other stores without copying it. Mirroring brings in databases and external catalogues.

Databricks runs in your cloud account (on Azure as Azure Databricks, a first-party Microsoft service). Your data sits in your own storage, governed by Unity Catalog. Compute is clusters, SQL warehouses or serverless, metered per workload in Databricks Units (DBUs).

On openness, the gap has narrowed. OneLake virtualises metadata so a Delta table can be read as Iceberg and an Iceberg table can be read as Delta. There are real limits: Parquet only, Iceberg V2 output, and equality deletes break conversion. Unity Catalog managed Iceberg tables are generally available, with external engines reading and writing through Unity Catalog's Iceberg REST Catalog API. Neither platform locks your data into a proprietary format. Both lock in your pipelines, security model and skills, which is where switching cost really sits.

The bridge between them matters most for a Microsoft shop. Fabric can mirror an Azure Databricks Unity Catalog as a catalogue item, generally available. Only the metadata is mirrored. The data is read in place through shortcuts. One catch: Unity Catalog permissions are not carried across. Fabric applies its own permission model.

Fabric sells capacity in F-SKUs, from F2 to F8192, measured in capacity units (CUs). Azure bills it per second with no commitment, or you reserve it for a year. In East US, pay-as-you-go list price is $0.18 per CU-hour. That puts an F64 at about $11.52 an hour, roughly $8,400 a month if left running. Microsoft says a reservation saves about 41% against pay-as-you-go. OneLake hot storage lists at $0.026 per GB a month. See the Microsoft Fabric pricing page.

F64 is also a licensing threshold. Per the Fabric licensing documentation, below F64 every person viewing Power BI content needs a Pro or Premium Per User licence. At F64 and above, viewers with a free licence and a viewer role can read reports. For a few hundred report readers, that alone can decide the SKU.

Azure Databricks charges DBUs per workload type, plus the Azure virtual machines underneath for classic compute. Serverless rates include the compute. East US Premium list prices are below. See the Azure Databricks pricing page.

1. Jobs compute: $0.30 per DBU-hour.
2. All-purpose compute (interactive notebooks): $0.55 per DBU-hour.
3. SQL Pro: $0.55 per DBU-hour. Serverless SQL: $0.70 per DBU-hour.
4. Serverless jobs: $0.45 per DBU-hour. Serverless interactive compute: $0.95 per DBU-hour.

All figures are list prices, checked October 2026, for East US. Other regions differ. Enterprise agreements, Databricks pre-purchase commitments and Azure reservations change the real number. My Databricks pricing guide goes deeper on DBUs.

What this means in practice:

1. Fabric is predictable but shared. One heavy Spark job can throttle the Power BI reports on the same capacity. Someone has to manage capacity like a shared server.
2. Databricks is granular but leaky. Each workload costs exactly what it uses. Clusters left running, oversized warehouses and all-purpose compute used for scheduled jobs are the usual leaks.
3. Compare total cost on real workloads. Price your top ten pipelines and your busiest reporting hour on both platforms. A spreadsheet of list prices proves nothing.

The table covers the points that usually decide it for a Microsoft-heavy organisation.

Criterion	Microsoft Fabric	Databricks (Azure Databricks)
Delivery model	SaaS, one tenant-wide OneLake	Platform in your cloud account and storage
Pricing	F-SKU capacity, pay-as-you-go or reserved	DBUs per workload, plus VMs for classic compute
Data engineering depth	Good for SQL, pipelines, Dataflows and Spark notebooks	Deeper: Spark tuning, streaming, declarative pipelines, CI/CD
ML and GenAI	Copilot in Fabric, Fabric data agents (GA), ML models and experiments	Model serving, MLflow, Genie, Agent Bricks
Power BI	Native; Direct Lake on OneLake	Through mirroring into Fabric, or DirectQuery and Import
Governance	Fabric permissions, OneLake security, Purview, sensitivity labels	Unity Catalog; Purview can scan it
Multi-cloud	Azure only	Azure, AWS and Google Cloud
Skills fit	Power BI, SQL and Microsoft data teams	Data engineers, Python and Spark, ML engineers

Power BI and Direct Lake. Direct Lake lets a Power BI semantic model read Delta tables in OneLake straight into memory, with no import refresh. It is the strongest reason to use Fabric. It needs a Fabric capacity, and the table limits rise with the SKU. A mirrored Azure Databricks catalogue is a supported Direct Lake source, so Databricks-built gold tables can feed Direct Lake reports.

ML and GenAI. Fabric data agents, which answer plain-English questions over OneLake data, are generally available. Some integrations, such as consuming them from Microsoft 365 Copilot, are still in preview. Copilot in Fabric needs a paid F2 or larger capacity and draws on it. On Databricks, Genie lets business users query governed tables in plain English. Agent Bricks is the platform for building and deploying custom agents in code. Databricks now lists Knowledge Assistant and Supervisor Agent as legacy and points new low-code work to Genie Agents. My Genie and Agent Bricks article covers this in detail.

Governance. Unity Catalog is the more mature single control plane for tables, models, lineage and fine-grained access across workspaces and clouds. Fabric governance is improving fast. In a Microsoft estate, Purview is often the enterprise catalogue already, and it can scan Unity Catalog metadata and lineage. My Unity Catalog governance guide covers the Databricks side.

Most Microsoft-heavy organisations I see do not pick one. They run Azure Databricks for ingestion, engineering and ML, then expose curated tables to Fabric for Power BI. With catalogue mirroring and Direct Lake, that pattern is now well supported.

It works when three things are true:

1. One platform owns each layer. Databricks owns bronze to gold. Fabric owns semantic models and reports. Nobody rebuilds the same table in both.
2. Security is designed twice, once. Mirroring does not copy Unity Catalog permissions. Decide who owns row-level and column-level rules in Fabric, and document the mapping.
3. Someone owns the bill for both. DBUs and capacity sit in different cost lines. Without one owner, each team optimises its own platform and the total goes up.

It fails when Fabric becomes a second engineering platform by stealth, and you end up with two gold layers that disagree. Where I have seen "use both" go wrong, it came down to two things: the integration between the platforms was not right, and nobody knew which platform owned the data. I'd rather set the rule on day one than untangle it later.

For ERP data (SAP, Oracle or Microsoft Dynamics 365), the same logic applies. Land and model it once, in one place. My notes on ERP modernisation and clean core explain why the ERP side matters as much as the platform.

Manufacturing. Plant data is the stress test. Historian and MES feeds, sensor streams at high frequency, quality and maintenance records joined to ERP. Fabric's Real-Time Intelligence (eventstreams and eventhouses) handles operational dashboards well. For large-scale streaming engineering, feature pipelines for predictive maintenance and ML on sensor data, I use Databricks. Streaming and machine learning on sensor and machine data is where it earns its place in my work.

Defence. Sovereignty and separation come first. Classified and unclassified environments stay apart. Export-controlled data (ITAR as a category) needs strict access control and audit. Programmes run for decades. Here, verify availability before you design anything, because the government clouds lag commercial Azure.

1. Fabric in GCC High. Per Microsoft Learn, checked October 2026, Fabric runs in US Gov Virginia and US Gov Texas. Core workloads are available, including lakehouse, warehouse, pipelines and Power BI with Direct Lake. Customer-managed keys, most mirroring sources, workspace Private Link and Copilot for Power BI are not supported. FedRAMP High authorisation for GCC High is still under assessment.
2. Azure Databricks in Azure Government. Per the Azure Databricks regional feature list, updated 1 October 2026, the US Gov regions do not support Databricks SQL or Unity Catalog. They also lack serverless and the newer AI features. Databricks has announced plans to bring the full platform to Azure Government. Confirm what is live in your region on the day you decide.

Outside the US, the same discipline applies. Check the regional tables for the exact Azure region you are bound to. Several Databricks serverless and AI features need cross-geography processing in some regions, which may be a non-starter for sovereign data.

Choose Fabric when:

1. Power BI is the main consumer and you want Direct Lake.
2. Your team is SQL, Power BI and Microsoft-first, with little Spark depth.
3. You want one capacity bill and SaaS operations, not platform engineering.
4. You have hundreds of report viewers and F64 licensing makes the numbers work.

Choose Databricks when:

1. Data engineering, streaming or ML is the hard part, not reporting.
2. You run on more than one cloud, or expect to.
3. You need Unity Catalog as one governance plane across many workspaces.
4. You need tight per-workload cost control and have the skills to manage it.

Choose both when you already run Azure Databricks well and the business lives in Power BI. Mirror the Unity Catalog into Fabric, use Direct Lake for reports, and write down who owns each layer.

If you already run a mature Databricks platform, do not migrate it to Fabric to save on BI. For a wider view, see my Snowflake vs Databricks comparison.

Run a two-week, like-for-like test on three real workloads: one heavy pipeline, one executive Power BI model, one ML or AI use case. Measure cost per run, refresh latency and the effort your team needed. Ask the vendors or your SI to price that exact set at your negotiated rates.

Ask each vendor three questions: what is GA versus preview in my region, what happens to cost when usage doubles, and how security works across the seam.

If you want an independent view on the platform decision or the test design, I help organisations with exactly this. You can book a 30-minute call.

Is Microsoft Fabric replacing Azure Databricks?

No. Azure Databricks remains a first-party Azure service, and Microsoft documents how the two work together. Fabric can mirror an Azure Databricks Unity Catalog, generally available, so Power BI can use Databricks tables through Direct Lake without copying data. Many organisations run both.

Is Fabric cheaper than Databricks?

It depends on the workload mix. Fabric is a shared capacity (East US list price $0.18 per CU-hour, about 41% less with a one-year reservation). Databricks charges DBUs per workload, plus VMs for classic compute. Price your own top workloads on both.

Can Power BI use Databricks data without Fabric?

Yes. Power BI connects to Databricks SQL warehouses in Import or DirectQuery mode. Direct Lake needs a Fabric capacity, and a mirrored Azure Databricks catalogue is a supported Direct Lake source.

Does Unity Catalog security carry over to Fabric?

No. When Fabric mirrors an Azure Databricks catalogue, it mirrors metadata and reads data through shortcuts. Unity Catalog policies and permissions are not mirrored, so Fabric's own permission model applies. Design and document access rules on the Fabric side.

Is Microsoft Fabric available in Azure Government?

Fabric runs in the GCC High environment in US Gov Virginia and US Gov Texas, with a narrower feature set than commercial Fabric. Customer-managed keys, most mirroring sources and Copilot for Power BI are not supported, per Microsoft Learn, October 2026. FedRAMP High for GCC High is still under assessment. Check the current list before planning.

Which is better for machine learning, Databricks or Fabric?

Databricks has the deeper ML and GenAI tooling: MLflow, model serving, Genie and Agent Bricks for custom agents. Fabric covers ML experiments and models, data agents (GA) and Copilot, and its data agents can be used from Microsoft Foundry (in preview). If ML is a core capability rather than an add-on, Databricks is usually the stronger base.