Microsoft Fabric and Azure Databricks at a glance

Renata's decision meeting on the data platform was set for November 24, 2026. Before it, she asked Nikolai for a one-page comparison of the two services the DP-900 outline names for large-scale analytics, Microsoft Fabric and Azure Databricks, with a note on Azure Synapse Analytics, which an earlier consultant had recommended. Nikolai turned the page into a clinic for Keiko, because she would be one of the platform's main users and needed to know what each piece did.

Why a unified platform?

Lessons 5 to 7 described the parts of an analytics solution: ingestion, a lake or warehouse, processing and reporting. A decade ago, each part was a separate product with its own storage, security and bill, and connecting them took much of a data team's time. Both Fabric and Databricks try to reduce that work by putting the parts on one platform with shared storage, shared security and a shared catalogue of data. They approach the problem from different directions.

Microsoft Fabric

Microsoft Fabric is a software as a service (SaaS) analytics platform. There are no servers or clusters to create: an organization buys capacity, measured in capacity units, and creates workspaces in which teams build items such as lakehouses, warehouses, pipelines, notebooks, semantic models and reports. Microsoft runs and updates everything. Fabric brings together several workloads, each aimed at a kind of work:

Everything in Fabric stores its data in OneLake, the single logical data lake for the organization, built on Azure Data Lake Storage Gen2. Tables are stored in the open Delta Lake format, so a table written by a Spark notebook can be queried by the warehouse's SQL engine and read by Power BI without copying it. Power BI's Direct Lake mode reads Delta tables in OneLake directly, combining the speed of imported data with the freshness of a live connection. Governance and security are shared: workspace roles control who can do what, Microsoft Purview integration catalogues and labels data, and Copilot assists with writing queries, code and reports.

For Harrow & Finch, Fabric's attraction was simplicity and the fit with tools people already used. Keiko knew Excel, Power Query and Power BI; Fabric's Dataflow Gen2 and Power BI were familiar ground. The company already used Microsoft 365 and Microsoft Entra ID, and Fabric uses the same identities and is administered from the same portals.

Azure Databricks

Azure Databricks is a data and AI platform based on Apache Spark, offered as a first-party Azure service built with Databricks. It is a platform as a service: customers create a workspace in an Azure subscription, and Databricks manages compute for notebooks, jobs and SQL queries, including serverless options. Data is stored in the customer's own cloud storage, typically Azure Data Lake Storage Gen2, in Delta Lake tables, the format Databricks created. Unity Catalog provides a central catalogue of data and AI assets with permissions, lineage and auditing across workspaces.

Databricks is strongest for data engineering at scale and data science and machine learning. Its notebooks support Python, SQL, Scala and R; its jobs orchestrate complex workflows; Databricks SQL provides SQL warehouses for analysts; and its machine learning tools track experiments and serve models. Organizations that run multiple clouds value that Databricks works similarly on Azure, AWS and Google Cloud. Teams with strong Spark and Python skills often prefer it.

The two are not mutually exclusive. Because both use Delta Lake, a company can do heavy engineering in Databricks and expose the results to Fabric and Power BI, for example by mirroring a Unity Catalog into Fabric or with shortcuts to the same storage. Nikolai said that question would come up only if Harrow & Finch's data science work grew much larger.

Azure Synapse Analytics

Azure Synapse Analytics is an earlier Azure analytics service that combined data warehousing with dedicated and serverless SQL pools, Spark pools and pipelines in one workspace. Many organizations still run it. Microsoft now presents Fabric as its main analytics platform and provides migration guidance and tools for moving Synapse workloads to Fabric. The current DP-900 outline names Azure Databricks and Microsoft Fabric for large-scale analytics, so Synapse appears in this course only as context. If you see it in older study material, recognize it as the predecessor whose ideas, such as SQL pools and integrated pipelines, carried into Fabric.

Thinking about cost

The two platforms charge differently. Fabric charges for capacity: a capacity of a given size is available for all workloads in its workspaces, whether used heavily or lightly, with pay-as-you-go and reserved options and the ability to pause some capacities. OneLake storage is billed separately. Databricks charges for compute in Databricks units consumed by clusters and SQL warehouses while they run, plus the underlying Azure virtual machines for classic compute, and storage is billed by the customer's storage account. Neither model is cheaper in general; the right one depends on how steady the workload is.

# Steady versus spiky workloads (illustrative numbers, not real prices)
hours = 730
capacity_per_hour = 2.50                 # a fixed capacity, always on
usage = {"steady": [1.0] * hours,         # busy all month
         "spiky": [3.0] * 60 + [0.0] * (hours - 60)}   # very busy for 60 hours, idle otherwise
per_unit_hour = 1.20                     # pay only while compute runs, per unit of work
for name, u in usage.items():
    capacity_cost = hours * capacity_per_hour
    usage_cost = sum(u) * per_unit_hour
    print(f"{name:7s} capacity {capacity_cost:7.0f}   pay-per-use {usage_cost:7.0f}")

steady  capacity    1825   pay-per-use     876
spiky   capacity    1825   pay-per-use     216

With these made-up numbers, a fixed capacity costs the same either way, while pay-per-use is cheaper for the spiky workload and dearer for the steady one. In practice Fabric capacities can also be paused or scaled, and Databricks offers committed-use discounts, so real estimates need the Azure pricing calculator and a pilot.

Harrow & Finch's recommendation

Nikolai's page recommended Microsoft Fabric for the Finch Data Hub. The reasons were the team's skills (SQL, Power Query and Power BI rather than Scala), the size of the data (hundreds of millions of rows, not hundreds of billions), the need for Power BI reports for 23 stores, the built-in real-time workload for the freezer pilot, and simpler administration for a small team. Databricks was noted as a future option if data science grew. The pilot was planned for January to April 2027, starting with the nightly sales report. The meeting on November 24 would make the decision.

Workspaces, items and capacity in Fabric

Keiko wanted to know what she would actually see on her first day in Fabric. Nikolai described the structure. A Fabric tenant belongs to the organization and uses its Microsoft Entra ID. Administrators assign one or more capacities to it. Teams create workspaces, each attached to a capacity, and in each workspace they create items: a lakehouse, a warehouse, a pipeline, a dataflow, a notebook, an eventstream, an Eventhouse, a semantic model, a report. Items in a workspace share its permissions and its capacity. Domains group workspaces by business area, such as finance or store operations, so that governance and discovery follow the organization's structure.

Workspaces are also how Fabric supports a sensible development process. A team can keep development, test and production workspaces, connect them to a Git repository so that changes to items are versioned, and use deployment pipelines to promote tested items from one workspace to the next. Nikolai planned exactly that for the Finch Data Hub, so that Keiko could change a report in development without breaking the version store managers used.

Inside Azure Databricks

A Databricks workspace is the environment where teams work. It contains notebooks for interactive code, jobs that run notebooks and scripts on a schedule, compute in the form of clusters or serverless resources, and SQL warehouses that analysts query with Databricks SQL or connect to from Power BI. Unity Catalog organizes data in a three-level namespace of catalog, schema and table, applies permissions and records lineage, and can govern several workspaces from one place. Delta Live Tables, now part of Lakeflow, lets engineers declare pipelines that keep tables up to date and enforce data quality rules.

For machine learning, Databricks includes tools to track experiments, register models and serve them for applications, which is why many data science teams choose it. Nikolai summed up the difference for Keiko this way: Fabric feels like an extension of Power BI and Microsoft 365 that grew to include data engineering, while Databricks feels like a data engineering and data science platform that connects well to Power BI.

Questions to ask when choosing

DP-900 does not ask candidates to design a platform, but it helps to know the questions organizations ask. What skills does the team have, SQL and Power BI or Python and Spark? How large and varied is the data? Does the company need real-time analytics as well as batch? Does it run in more than one cloud? How does it prefer to pay, a fixed capacity or usage-based compute? How much administration can it take on? And what does it already use, since a company with Synapse, Databricks or Power BI investments will want to build on them. Harrow & Finch's answers pointed clearly to Fabric; another company's could just as clearly point to Databricks.

What Keiko will actually use

For the pilot, Keiko's day-to-day tools would be a small set of Fabric items: a Dataflow Gen2 for the supplier price lists, the SQL analytics endpoint of the gold lakehouse for checking figures, a semantic model in Direct Lake mode, and the Store Performance report. Nikolai would own the pipelines and notebooks. That split, engineers owning ingestion and analysts owning models and reports, is common on Fabric and reflects the data roles from MSAZ-120.