Microsoft Fabric: The Positive, Negative, and Unpleasant

I began a greenfield deployment of Fabric, Microsoft's next-generation data platform, a few weeks ago. It promises unified experiences for different personas, such as scientists, analysts, and data engineers. Fabric's offer is commendable: a single location for all of your data workloads that is well-managed and elegantly connected. But there are differing views on Fabric, which has been on general availability (GA) for more than a year. Why is that? Based on my own experience, I will examine Microsoft Fabric's advantages, disadvantages, and ugly aspects in this essay.

The Positive
Let's get off to a good start. There are many positive aspects of Fabric. First, the concept. Fabric is a platform for Software as a Service that lets users design and manage their own data pipelines. It offers solutions for a scientist who conducts experiments and implements machine learning models, a data engineer who must perform ELT from a source system, and an analyst who models data and creates reports that support business decisions. Because it is a software as a service (SaaS), it may be accessed directly from the browser, appealing to Apple acolytes. Its pricing is transparent and adheres to the SaaS standards.


OneLake is yet another fantastic feature of Fabric. A centralised storage solution for your entire company that has embraced Delta Lake's open storage model. This implies that you can access your data from a wide range of sources and in various cloud environments. When used with Spark, a notebook runtime, this performs remarkably well. Queries and transformations of data stored in files at several locations feel fantastic. Although this technology has been there for a while (for example, AWS Athena or other rivals), it's fantastic that Microsoft now completely supports it as well. They did a fantastic job.

I've interacted with support regarding Fabric three times in the last few weeks. It's really fantastic. Even in the absence of a costly support plan, responses are prompt and courteous. The same is true with the Fabric community, which includes both the official community and a number of subreddits. The developers and support staff are sincere and won't abandon you. I recognise that I feel so strongly about this that perhaps now would be a good time to clarify that I have no affiliation whatsoever with Microsoft or its support division.

The Negative
The absence of support for Infrastructure as Code is, in my opinion, one of the main drawbacks. In general, it is not a good idea to rely on ClickOps for significant production workloads. Although there have been advancements in this field, like as the emergence of a Fabric Terraform supplier, these advancements have been classified as not yet suitable for production. To encourage additional adoption, this must be altered.

Another thing that irritates me is that it seems like services are thrown together without any consideration for standards. I want to use two instances to demonstrate this. Back in the day, we called these Data Pipeline elements in Fabric Azure Data Factory pipelines (how nostalgic!). The DataFlow objects are next to that. To put it simply, these things are conceptually identical in that they are used to transfer data between locations, either with or without transformation. They are using various underlaying technologies, which is perfectly acceptable, which is why they seem as distinct goods. The distinction in how these things are managed, however, is what I do find perplexing. For instance, you can alter the Data Pipeline at any moment, but you must first assume ownership of the item in order to alter the DataFlow. As an additional illustration, you may save a copy of a Data Pipeline and transfer it between workspaces. For a Data Flow, you must first export it locally, thus you can't do this. Even though these are small annoyances, they demonstrate that the Fabric experience is not as smooth and polished as the marketing staff would have you think. It was perplexing and annoying.

The various powers that Fabric offers were another perplexing feature that I encountered. Before I go any further, I would want to state that, although I am aware that Microsoft is actively attempting to simplify this, the reality remains that they now sell and offer this to customers. As of February 2025, let's examine every licensing option available:


I am aware that Fabric's past is the source of this complication. PowerBI was the previous option, however I'm not sure why the Trial and Fabric capacities differ. The sole distinction between them is that one is compensated while the other is not. One does not just leave a trial capacity, which is why I believe this to be an issue. If you're curious, the issue was that, for some reason, you couldn't move goods between areas. It took me two support tickets to figure out how this works.

Finally, we must discuss Purview. Purview is assigned to manage the platform's governance component. The issue is that Purview has a thorough integration with M365 but not with Azure or Fabric at this time. Roles and permissions have caused me a lot of headaches. Let's say the experience isn't as smooth as advertised.

Naturally, I haven't addressed all of the minor annoyances (like AI, since they had to apply AI to this, of course). It wouldn't feel fair either. Microsoft is clearly making an effort, but in my opinion, they rushed into the Fabric industry. I don't understand why this feature and service, out of all those that have been in public preview for the longest, went to GA at this point.

The Unpleasant
In conclusion, you will be really disappointed if you were hoping to transfer all of your existing data workloads from Databricks or something similar to Fabric (oh my, he mentioned the term!). Even though the concepts underlying the two services are similar, Fabric is still far behind its rivals in terms of production readiness and capabilities.

Nevertheless, I do think there are applications for Fabric in its current state. It appears to be excellent for bringing reporting capabilities closer to their sources and giving analysts complete ownership of solutions. This also applies to other disconnected and contained solutions. Fabric can handle certain use scenarios, which are excellent for implementing Data Products in accordance with the Data Mesh principles. Fabric is ideally suited to enabling Proof of Concepts and tiny products, particularly in situations when a company's data maturity is low.

But now for the ugly part. These Proof of Concepts and workloads should ideally advance and expand. I start to worry a little at this point. Before I trust fabric to handle actual things, it needs additional work.

I appreciate you reading. I would love to hear about your experiences!
Hi There, I'm Yahya, and I enjoy sharing knowledge and experiences.