Joey on SQL Server

Fabric's Growing Pains: Meeting the Needs of Power BI and Enterprise Customers

Microsoft's challenge with Fabric lies in balancing the needs of data engineers and smaller Power BI-focused users, while addressing concerns around feature gaps, security and usability in its expansive analytics suite.

• By Joey D'Antoni
• 01/22/2025

A firmly held opinion is that as technology professionals, we don't look to our history enough -- both recent and very past. I can understand why this is the case, as technology always wants to move forward. But by not looking back, we tend to repeat many of the same mistakes we've made.

Let's think about SQL Server, Microsoft's relational database that became an overwhelmingly successful product through its 30+ year history. SQL Server became successful because it had all the enterprise-class features. Still, more importantly, it was much cheaper and easier to use than its competitors like Oracle and DB2. I was an Oracle DBA for much of my early career and still dabble (and that fact grounds my opinion).

Like SQL Server before it, Power BI was game-changing software. Launched initially in SharePoint as part of the nascent Office 365 suite in 2012, breaking out Power BI into a standalone product that dramatically undercut the pricing of competitors like Qlik and Tableau, delivering another winning product to Microsoft. In both cases, the definition of success for the product was not simply pricing or technology.

Microsoft, particularly in its data platform organization, has done an excellent job building communities around its products through sponsorship of user organizations, listening to users and integrating that feedback into the product, and, frankly, the hard work and efforts of members of various product groups. Microsoft has made similar efforts with Fabric and is doing an excellent job of building a community. However, things are still lacking in many ways on the product side. In this article, I want to examine why I still see gaps in Fabric and what my fundamental concerns are.

Let's talk about Fabric, and what makes up Fabric's complicated set of tools:

• Power BI
• Data Warehouses
• Data Lakes
• Real-time Analytics
• Databases
• Data Engineering
• Machine Learning

The first technical challenge is that many of these products overlap just enough to confuse customers but are insufficient to completely share development paths (data lakes and data warehousing being an exception). Another challenge is that these components have vastly different audiences. Recently, in social media circles, there has been some commentary from members of the Power BI community that they feel left behind by the big push from Microsoft on Fabric.

My MVP colleague Eugene Meidinger wrote an excellent blog post on the topic that inspired this column. While I can understand the feelings of the Power BI folks, the challenges here are more profound than that.
Back to that history topic, let's look at the recent history of data analytics. Many modern data engineering practices go back to around 2005 when some engineers at Yahoo named Doug Cutting and Mike Cafarella developed Hadoop, a distributed approach to large-scale data analysis. Hadoop was ultimately open source and released in 2011, and I worked on Hadoop early (2012) during my time at Comcast. While incredibly powerful, Hadoop was complex to set up and configure and required advanced skills just to get started. Hadoop also made limited use of RAM and was replaced mainly by Spark. This similar large-scale clustered computing is used across most data engineering practices today. Spark is a key component of both Fabric and its competitor, Databricks. While Databricks, Snowflake, and the data engineering parts of Fabric are much easier tools to use than the early days of Pig and the other landscape of Hadoop tools, they are still advanced tools that go well beyond the typical skills of a business data analyst.

Most modern data engineering practices have evolved through large-scale deployments -- it's a very code-first practice, with lots of Python, Scala and, yes, SQL. This audience has vastly different demands and expectations from business users building dashboards in Power BI. Yes, both audiences depend on having quality data, presumably in a star schema, but that's where the similarities end. Trying to cater to both audiences in a single product will be challenging in the best case. I think this split focus is why we see so many complaints around Fabric. let's focus on two specific things.

I don't want to worry about pricing here, but Fabric's pricing is reasonable and scalable. Community members' loud demand has been for Microsoft to deliver "per user" pricing to lower the cost for smaller organizations. I think those smaller firms are largely driven by those who just want the reporting and "lightweight" data engineering components of Power BI.  On the other hand, enterprise customers aren't asking for cheaper licenses but for private networking, data loss prevention, a common and more granular security model, and better monitoring and management tools. In Power BI, the only word that existed before Fabric, where it was "just a reporting tool" (note: it was always more than that), but as a hub of data engineering, warehouses, and databases, those large organizations have more significant security and management concerns.

Microsoft is well known for its focus on enterprise customers. However, the history of the Microsoft business intelligence stack has always focused on smaller organizations. While tools like SQL Server Analysis, Integration and Reporting services were also broadly adopted by enterprises, they represented approachable tools that small and medium businesses could adopt. This trend continued with Power BI, which was cheaper and easier to use than its major competitors.

Microsoft is trying to support those enterprise demands and sell as much Fabric as needed to meet its investment, which means that its focus here needs to be on those enterprise requirements. However, I've heard the term “citizen developers” a few times in recent calls with Microsoft, and a lot of design decisions seen in Fabric reflect more of a focus on those smaller customers rather than larger, more data-mature customers. For those new to the term, "citizen developers” refers to low-code users -- the kinds of business analysts who might develop a Power BI dashboard. Developing for these types of users is fine, but at the same time it can conflict with the features data engineers and developers need. Power BI has struggled to balance requirements between these users and enterprise users. For example, source control of Power BI reports has always been challenging (although it has improved recently). By adding data engineering and warehouse functions into Fabric, that divide grows further.

Microsoft's Power BI product has been wildly successful, and many of its product teams are leaders in the development of Fabric. While breaking down barriers and innovating drove Power BI to its success, large-scale data analytics solutions have different user demands than reporting systems.

Existing Power BI customers can be overwhelmed by the enormity of the Fabric suite and are concerned about their path forward as "just Power BI customers" based on changes to licensing and the general marketing and community messaging coming from Microsoft. At the same time, large customers demand more robust controls and management, and are frustrated that many features like OneSecurity have been delayed, or only work halfway. I'm confident that we won't see Power BI split out of Fabric. Still, Microsoft will continue to struggle to meet the needs of both Fabric customers in the medium term. Making challenging program management and marketing decisions can ensure both messaging and features align with the demands of these customer constituencies.