Deep-Dive: Microsoft Fabric Warehouse Internal Architecture (Polaris, V-Order & Lakehouse Tradeoffs)
Hi Fabric Community, I’ve spent the last few weeks researching and writing a complete architectural guide on the internals of the Microsoft Fabric Warehouse, and wanted to share some key design patterns and takeaways with you. When moving from Azure Synapse Dedicated Pools or SQL Server to Fabric, the mental model shift can be challenging—especially regarding serverless execution and open-standard storage. Here is a summary of the 3 most critical findings from my architecture breakdown: 1. The Polaris Engine Mechanics Unlike traditional Dedicated SQL Pools which bind compute to VM instances, Fabric Warehouse runs on the Polaris distributed SQL engine. Query compilation is split into stateless metadata services. Compute nodes are allocated dynamically per query. There is no local page storage; instead, the engine reads and writes open-source Delta Parquet format files directly in OneLake. 2. The Reality of Constraints A common point of confusion is table constraints. Fabric Warehouse allows you to define Primary Keys, Foreign Keys, and Unique Constraints, but they are not enforced during data ingestion. They serve purely as metadata for the query optimizer (to improve join paths). You must handle data validation/enforcement upstream in your Spark/Dataflow pipelines! 3. Direct Lake & Cold Queries Power BI's Direct Lake mode is a game-changer because it bypasses the SQL endpoint and queries the Delta Parquet files directly. However, if the dataset size exceeds the F-SKU memory limits, the query falls back to DirectQuery mode. This fallback forces the engine to run SQL queries on the SQL endpoint, introducing cold-query compilation times. I have published the full 11,000-word engineering handbook covering capacity planning, monitoring DMVs, security setups (RLS/OLS), and a retail case study. If you are planning an enterprise migration or studying for the DP-600 / DP-700 exams, check out the deep dive here: 👉 Read the Microsoft Fabric Warehouse Architecture & Performance Guide Would love to hear how your teams are managing cold query compilation and metadata cache warming on Fabric SQL endpoints. Let’s discuss below!
Unable to create Eventhouse
I'm an admin on Fabric and am working on the End-to-End Real-time intelligence tutorial. The following screenshot of my Fabric Capacity Metric app is showing statitics with high capacity usage for three workspaces that have been deleted more than 40 hours ago: From Capacity Metric Compute tab: From Health tab: Even more than 40 hours after deleting those 3 workspaces with hig capacity issue, I'm still getting following error when trying to create an Eventhouse: Eventhouse item could not be created because your capacity has reached its maximum limit. Contact the capacity administrator for help. Can someone please help resolve the issue?
Fabric Apps Not in UK
There doesn't seem to be any timeline to rollout Fabric apps in the UK regions; this is a bit of a nightmare for GDPR reasons. It feels like Databricks hosted in the UK with any visualisations or apps we choose would be better. I think it's quite annoying to not have a timeline, and makes it hard to have a full strategy.If you could improve one thing in Microsoft Fabric tomorrow, what would it be?
No platform is perfect-including Microsoft Fabric. While I'm genuinely impressed by how quickly the platform has evolved, there are still areas where I think the experience could become even better. If the Fabric product team gave you one opportunity to improve the platform tomorrow... What would you choose? Would it be: • Better monitoring? • Improved CI/CD? • More governance capabilities? • Better Git integration? • Performance improvements? • Licensing or capacity changes? • Something completely different? I'm interested in hearing opinions from people using Fabric every day. Sometimes the best ideas come from real customer experiences rather than feature announcements. What would be your one improvement?
