Microsoft Fabric is a new product that has only been around for months. But it has quickly positioned itself as a powerful all-in-one analytics platform, integrating data engineering, data science, and business intelligence. As an independent data architect, I’ve tested Fabric and seen its potential in real-world applications as well as areas for improvement.
In this blog post, I’ll break down 10 things Microsoft Fabric must improve to better serve enterprises and everyday users alike.
Table of Contents
1 - Data Stores
The first thing Microsoft Fabric must improve is data stores. Fabric currently offers three main options: Data Warehouses, Lakehouses, and Fabric Databases. While variety can be beneficial, it also creates confusion.
For most organizations, deciding which store to use can be unnecessary and complex. Ideally, Fabric could present a more streamlined system to users, and essentially merge its offerings into a single, SQL-enabled Lakehouse that’s capable of both data updates and queries. This approach makes adopting the platform much smoother.
2 - Target Audience
Microsoft Fabric, with its numerous components, can be confusing even for developers. For instance, the rebranding of Power BI has left many business users scratching their heads.
Microsoft Fabric combines the worlds of Power BI, data engineering, and advanced analytics. While that’s powerful, it has blurred lines between communities and user groups. Power BI’s traditional aim was to put the power of data at the fingertips of its users, but with Fabric, discussions can often veer into topics that are not relevant to most users, such as data warehouses, Spark, and dataflows.
Microsoft needs to find a way to bring together the experiences of different user personas, without losing the momentum that the Power BI community consistently generates.
3 - Capacity Units
The next thing Microsoft Fabric needs to improve is its capacity units. Fabric uses Capacity Units (CUs) to measure compute. But they’re not a guarantee that your applications will run smoothly. One thing that can happen is that an overnight orchestration spike can cause dashboards to fail for users in the morning.
Microsoft should replace rigid quotas with a dynamic pay-as-you-go model that charges users based on actual usage rather than penalizing them for exceeding arbitrary limits.
4 - Dataflows Gen2
I love the idea that Dataflows Gen2 empowers users to apply transformations, clean their data, and do all the hard work. There is a vast library of 100+ connectors and Power Query transformations, giving it the flexibility it needs. However, they consume too many capacity units even for small tasks, making Dataflows Gen2 expensive.
Since this is not a scalable solution, it is impractical to use Dataflows as the default method for importing data into the system. This inefficiency is one of the important things Microsoft Fabric must improve on.
5 - Focusing on One Product
If you have been in Microsoft’s ecosystem long enough, you’ve seen several changes in the past years. You’ve seen the cycle: SQL Server → Azure Data Factory & Synapse → Microsoft Fabric.
While we expect innovation, too many product shifts shorten the lifecycle of enterprise data warehouses. These constant changes can cut the lifespan of these systems down to just 5–7 years.
Fabric needs to provide long-term stability and clear guidance, rather than just being the “latest iteration”. There should be more focus on developing the capabilities of Microsoft Fabric and less on releasing new capabilities for Azure analytics products.
6 - OneLake
OneLake was pitched as a “single source of truth” that would eliminate data duplication. It’s essentially a logical virtualization layer. In reality, data is still replicated behind the scenes when using Fabric databases or Eventhouse, so this does not line up with the original promise.
Until true single-storage is possible, Microsoft will need to reset its expectations and iron out any discrepancies across Fabric components.
7 - Number of Microsoft Fabric Capacity
In Microsoft Fabric, a capacity is the compute power that runs your workload. Just like you wouldn’t run all applications on a single machine, you also shouldn’t place every Fabric workload on one capacity. Massive data transformation in one capacity can slow down machine learning models and frustrate users.
Best practices often require multiple Fabric capacities—for dev, test, and production environments, as well as segregating workloads. Large-scale enterprises will need substantial capacity, one for data processing and others for reporting, machine learning, and analytics. The problem? You cannot share unused capacity units with another, as it results in inefficiency and higher costs.
Features like capacity pooling or borrowing unused units would make managing workloads far more flexible.
8 - Medallion Architecture
Looking at the Medallion Architecture in Fabric, we’re seeing a three-layered approach: Bronze (raw data), Silver (validated data), and Gold (enriched data). Although helpful in concept, it’s not changing the way we’ve been working with data, such as clean, transform, and serve.
For many organizations, explaining Medallion does not add any real value when the core process remains the same. Microsoft should focus less on marketing buzzwords and more on making it easier to adopt and get results.
9 - Alerts
Compared to Azure, Fabric’s alert and monitoring are underdeveloped. Alerts are a feature that help you detect issues and address them before users notice anything. Azure offers robust options like pipeline failure alerts, action groups, and Logic App remediation. In contrast, Fabric requires manual work and customized alert systems.
Microsoft could align the monitoring aspect of Fabric with Azure’s superior alerting system by integrating the two, thereby granting administrators more visibility and control over their services.
10 - Code Version Control
Version control in Fabric is a step forward, but it is currently limited to higher licensing tiers. Many companies still use Power BI Pro or Premium Per User, and they’re left out.
Expanding version control across all tiers is one of the things Microsoft Fabric must improve to boost governance, collaboration, and best practices. This standardization will benefit customers by minimizing expensive upgrades.
Final Thoughts
Microsoft Fabric is a bold step forward, uniting analytics into a single platform. However, to truly succeed, there are 10 things Microsoft Fabric must improve. These include simplifying data stores, clarifying its target audience, fixing capacity inefficiencies, and improving alerts.
As a practitioner, you may want to be on board with Fabric’s vision and acknowledging that there are real challenges that need immediate attention. Thanks to community feedback and Microsoft’s track record of iteration, many of these gaps can be closed.
Frequently Asked Questions
Question: Is Microsoft Fabric replacing Azure Synapse Analytics and Data Factory?
Answer: Not exactly. While Microsoft Fabric brings together capabilities from Synapse, Data Factory, and Power BI into a single platform, those existing services still run and are supported. Over time, Fabric will become the primary unified platform, but organizations can still use their existing Azure solutions alongside it.
Question: How does Microsoft Fabric licensing work?
Answer: Fabric is licensed through capacity units (CUs), similar to how Power BI Premium is licensed. Each workload you run consumes CUs, and the tier you purchase (e.g., F2, F32, F64) determines how much capacity you have. Unlike pure pay-as-you-go models, workloads stop when they exceed capacity, which is one of the current challenges with Fabric.
Question: Can I use Microsoft Fabric with my existing Power BI setup?
Answer: Yes. Fabric is designed to be fully integrated with Power BI. If you already use Power BI Premium or Premium Per User, you’re part of the Fabric ecosystem. This means your existing reports, datasets, and dashboards can run alongside new Fabric workloads like Lakehouses and Data Science models.
