In Short: The Warehouse Experience, Minus the Second Copy
Databricks SQL is the platform's answer to a fair historical criticism: the lakehouse was engineer-friendly and analyst-hostile. It packages SQL warehouses (managed endpoints, including serverless), the Photon engine, and a familiar SQL workbench - editor, queries, alerts, dashboards - over the same Delta tables engineering already maintains. The pitch: warehouse-grade SQL performance without copying data into a separate warehouse product.
For BI leaders the question is practical: can it serve the reporting layer? The short answer is yes, credibly, with design discipline - and the interesting decisions are about where it sits relative to Power BI and Fabric.
The Pieces That Matter
SQL warehouses. Compute endpoints sized like T-shirts, spun up per workload. Serverless warehouses start in seconds and bill while used, which matches the spiky shape of BI traffic far better than an always-on cluster; classic warehouses remain for estates that want tighter control. Either way, analysts get a connection string, not a Spark tutorial.
Photon. The vectorised engine underneath, transparent to users, that moved lakehouse SQL from "acceptable" to genuinely fast on typical BI shapes: joins, aggregations, star-schema scans. Combined with sensible table maintenance - the format rewards the same habits on every platform - interactive dashboards over large Delta tables are routine.
Governance included. Every query runs through Unity Catalog: permissions, row filters, lineage and audit apply to the analyst exactly as to the engineer, which is what makes self-service defensible.
Serving Power BI From It
The Power BI connector is mature: Entra ID sign-in, import or DirectQuery, and support for the usual enterprise patterns. Three design notes from the field.
- Import mode remains excellent for classic dimensional reporting: schedule refreshes from a warehouse, and the lakehouse is just a very good source
- DirectQuery against a serverless warehouse works for large or fresh data, with the familiar caveats: model discipline, measure pushdown, and warehouse sizing decide user experience
- Concurrency is a sizing question: BI crowds are bursty, so autoscaling warehouses and separating engineering compute from BI compute keeps the two workloads honest
The alternative pattern for Microsoft-centric estates: keep Databricks as the engineering platform and serve BI through Fabric instead - shortcuts or Unity Catalog mirroring expose the same Delta tables to Direct Lake semantic models. Which door you choose is mostly about where your BI governance and skills live, a trade we walk through in the platform comparison.
The Honest Assessment
Databricks SQL removed the last structural excuse for the two-platform tax - one copy of data can now serve engineering and BI. What it does not remove is the modelling work: a lakehouse serving BI still needs conformed gold layers, owned definitions and tested security, exactly as a warehouse always did. Platforms moved; the discipline did not.
Sources and Further Reading
Frequently asked
The SQL-first workload of the Databricks platform: SQL warehouses (compute endpoints, including serverless) that run ANSI SQL over Delta tables at interactive speed, plus a SQL editor, alerts and dashboards. It exists so analysts and BI tools can use the lakehouse without touching Spark notebooks.
A managed compute endpoint sized in T-shirt sizes that serves SQL queries. Serverless warehouses start in seconds and bill per use, which suits spiky BI traffic; classic warehouses run on managed clusters you control more tightly.
Databricks' vectorised query engine, written for modern CPUs, that accelerates SQL and DataFrame workloads substantially without code changes. It is the reason lakehouse SQL performance became competitive with dedicated warehouses.
Yes, with a first-class connector supporting import and DirectQuery, plus Entra ID authentication. Many estates serve Power BI straight from SQL warehouses; the design choices are the same as any DirectQuery source - model discipline and warehouse sizing decide the experience.
Increasingly, no - that is the lakehouse thesis: one copy of data in Delta, warehouse-grade SQL on top. Teams deeply invested in T-SQL tooling or Fabric's integrated experience may still prefer a Fabric warehouse; the data itself no longer forces the choice.
