One engine, two surfaces#
When you query a Fabric Warehouse or the auto-generated SQL analytics endpoint on a Lakehouse, you're touching the same engine, not two similar-looking implementations. That engine is Polaris, Microsoft's cloud-native distributed SQL query engine, originally built for Azure Synapse [S1]. It was designed around two goals: converge data-warehouse and big-data workloads onto one engine, and fully separate compute from state so execution is stateless and elastically scalable [S1].
That "separate compute from state" goal is what you experience day to day. The Fabric Warehouse and the SQL analytics endpoint share one underlying distributed processing architecture, and the backend is serverless: compute scales up and down automatically to match workload demand, rather than you provisioning it [S2]. This holds specifically for the endpoint auto-generated over a Lakehouse's Delta tables too — it and a full Warehouse run on the same stateless distributed query engine, not separate SQL stacks [S3].
A concrete example#
A colleague creates a Lakehouse and loads a few Delta tables into it. Fabric automatically stands up a SQL analytics endpoint so those tables are queryable with T-SQL — no separate provisioning step. Later, the team also stands up a dedicated Fabric Warehouse for reporting. Both the Lakehouse's endpoint and the standalone Warehouse execute queries through the same Polaris engine [S1] [S3]. Neither required picking a node count or cluster size; Polaris scales its own compute to the query load [S2].
What goes wrong#
- Assuming the SQL analytics endpoint is a lightweight, separate query layer from the Warehouse. It runs on the same distributed engine, not a different product bolted on for convenience [S3].
- Expecting to size or provision Polaris compute yourself. The backend scales autonomously; there's no cluster or node count to set [S2].
- Treating Polaris as Fabric-specific. It originated as the distributed SQL engine for Azure Synapse, built for data-warehouse/big-data convergence before Fabric existed [S1].
Where this lesson stops#
This is a short lesson because the knowledge base currently holds only three distinct verified claims about Polaris at the conceptual/practitioner depth. Deeper mechanics — query compilation, the cell-based data model, fault tolerance, and scheduling — live at the architect and internals depths in the full Polaris article, not here.