In Short: The Engineering-Grade Lakehouse, First-Party on Azure
Azure Databricks is the Azure edition of the Databricks platform: a code-first environment for data engineering, analytics and AI, running managed Spark over Delta Lake tables in your own Azure storage, governed by Unity Catalog. Unusually, it is a genuine first-party Azure service - in the portal, on the Azure bill, wired to Entra ID - which is why it keeps appearing in otherwise Microsoft-pure estates.
For teams weighing it against Fabric: they share the lakehouse idea and the Delta format, and differ mainly in who they were built for. Databricks assumes engineers; Fabric assumes an integrated platform serving everyone from engineers to report consumers. Our full comparison covers that decision; this post covers what Databricks actually is.
The Working Parts
- Workspaces and notebooks - the primary interface: collaborative notebooks in Python, SQL, Scala and R, backed by Git, increasingly assisted by the platform's AI
- Compute - classic clusters you size and manage, and serverless options where the platform does; the Photon engine accelerates SQL and DataFrame work substantially
- Delta Lake storage - tables live as open Delta Parquet in your ADLS storage account, not inside a proprietary store
- Unity Catalog - the governance layer: one catalog of tables, files, models and functions with permissions, lineage and audit across workspaces
- Databricks SQL - warehouses (including serverless) that serve BI tools at interactive speed, the piece that made Databricks a credible Power BI backend
- ML and AI tooling - MLflow-based experiment tracking and model registry, plus the newer AI/BI and Genie natural-language layer
- LakeFlow - the consolidating brand for ingestion, declarative pipelines and job orchestration, covered in our LakeFlow guide
What It Is Genuinely Good At
Databricks earns its reputation where engineering depth pays: heavy transformation pipelines over large volumes, streaming, demanding ML with real MLOps ceremony, and multi-team estates that want medallion designs with fine-grained control over compute, code and deployment. Teams that think in Git, tests and infrastructure-as-code find the platform speaks their language natively.
The flip side is the same fact: it assumes that team exists. Organisations without engineering depth find Databricks powerful and unattended - which is often the moment Fabric's SaaS posture, or a managed partner, enters the conversation.
The Azure Integration That Matters
Being first-party is not branding. Identity is Entra ID end to end; networking supports private endpoints and your own VNet topology; storage is your ADLS account, so the data outlives any platform decision; and billing lands on the Azure agreement procurement already signed. For Microsoft-centric organisations this removes most of the friction that multi-cloud platforms carry.
It also enables the pattern we increasingly recommend: Databricks engineering where it is strongest, Fabric consuming the results - via OneLake shortcuts or Unity Catalog mirroring - so BI, Copilot and the business live in the Microsoft experience while engineers keep their tooling. Both-and is a real architecture now, not a compromise.
Sources and Further Reading
Frequently asked
A cloud platform for data engineering, analytics and AI, built by Databricks and sold as a first-party Azure service. Teams write code (mostly in notebooks) that runs on managed Spark compute over data stored in Delta Lake format in their own Azure storage, governed by Unity Catalog.
It is a first-party Azure service operated in partnership with Databricks: it appears in the Azure portal, bills through Azure, and integrates with Entra ID and Azure networking, while the platform itself is Databricks' own. That first-party status is why it sits so comfortably in Microsoft-centric estates.
Code-first data engineering at scale, demanding Spark workloads, machine learning with serious MLOps, and now a strong SQL and BI-serving story via Databricks SQL. Its centre of gravity is engineering teams who want full control and are comfortable in notebooks and Git.
They overlap on the lakehouse core and differ in personality: Fabric is SaaS, integrated and BI-centred; Databricks is engineering-centred with deeper control. Both build on Delta Lake, which is why coexistence works - shortcuts and Unity Catalog mirroring let Fabric consume Databricks-maintained data directly.
Consumption: you pay Databricks units (DBUs) for the compute you run plus the underlying Azure infrastructure, with serverless options shifting more of that to per-use. There is no per-user licence; cost management is workload engineering, similar in spirit to managing Fabric capacity.
