High CU consumption after enabling Workspace Monitoring
Hi everyone, I’m wondering if anyone else has experienced very high CU consumption after enabling Workspace Monitoring in Microsoft Fabric. In my case, I tested it on an F4 capacity, and the additional CU usage was significant enough that the capacity became difficult to use for the actual workloads running in the workspace. I understand that Workspace Monitoring creates and uses Fabric resources for collecting and storing logs, so some additional capacity consumption is expected. However, the overhead I’m seeing feels quite high and it makes no sense to enable this feature I’m interested if there are any answers on following questions: Have you noticed a significant CU increase after enabling Workspace Monitoring? Is the impact especially noticeable on smaller capacities such as F2/F4/F8? Have you found any practical way to reduce the monitoring overhead? Are you using Workspace Monitoring in production on smaller capacities, or do you avoid it because of the CU cost? At the moment, my concern is that on smaller capacities the monitoring workload itself can consume enough capacity to materially affect the workloads it is supposed to help monitor. Would be interested to hear about other people’s experience and whether this is expected behaviour.
Unable to commit the following item type "Activator"
Hi Fabric Community, I'm running into an issue with a type activator in Fabric and could use some guidance from the community. When attempting to commit the activator to my repo, I received the following error message: "We weren't able to commit the following item: Please check the technical details for more information " I'm not entirely sure what this error means or how to troubleshoot it. If anyone has come across a similar issue with type activators in Fabric or has any insights into what might be causing this, I'd really appreciate your help. Thanks in AdvanceDeep-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?
