A few weeks ago, I started a greenfield implementation of Fabric, Microsoft’s next-gen data platform that promises unified experiences tailored to various personas, including Data Engineers, Analysts, and Scientists. The proposition of Fabric is admirable: a one-stop shop for all your data workloads, seamlessly integrated and well-governed. However, Fabric has been in General Availability (GA) for well over a year now, and the opinions are divided. Why is that? In this post, I will explore The Good, The Bad, and The Ugly of Microsoft Fabric based on my personal experience.
Image of how Microsoft Fabric is marketed
The Good
Let’s start on a positive note. There are a lot of things to like about Fabric. First of all, the idea. Fabric is a Software as a Service platform that enables its users to create and run their data workflows. It has solutions for a data engineer that needs to perform ELT from a source system, an analyst that models data and build reports that fuel business decisions, to a scientist that experiments and deploys with machine learning models. It being a SaaS, it is natively accessible from the browser, enabling Apple fanboys (guilty as charged). Following the SaaS principles, it also has transparant pricing.
Another great thing about Fabric is OneLake. A centralised storage solution for your whole organisation, that has adopted the open storage format of Delta Lake. This means you can connect with your data from a whole bunch of origins, across different cloud environments. This works exceptionally well in combination with Spark, available as a notebook runtime. It feels magical to query and transform data that is stored in files on different locations. Even though this technology has existed for some time (e.g. AWS Athena, or other competitors), it is great that Microsoft fully supports this feature now, too. They really nailed this.
Over the past weeks, I’ve dealt with support around Fabric on three separate occasions. It’s truly awesome. Responses are swift and professional, even without an expensive support plan. Same goes for the community around Fabric: the official one, as well as various subreddits. The developers and support people genuinely care and will not leave you hanging. I realise I’m so positive about this that maybe it’s a good time to mention that I’m not affiliated with Microsoft — or its support department — in any way.
The Bad
One of the major disadvantages in my eyes, is the lack of support for Infrastructure as Code. Relying on ClickOps for important production workloads is generally a bad idea. Although there are developments in this space — in the form of a Fabric Terraform provider — these developments are labeled as not production ready. This needs to change to stimulate further adoption.
Another frustration I had is that it feels like services are slapped together, without giving a second thought about standardisation. I want to illustrate this using two examples. In Fabric, Data Pipeline items contain something that we used to call Azure Data Factory pipelines back in the day (oh, the nostalgia!). Next to that, we have the DataFlow items. Both items are conceptually similar (simplified explanation: they exist to move data from one place to another, with or without transformation). The reason they materialise in separate items is because they are using different underlaying technologies, which is completely fine. What I do find confusing is the difference in management of these items, though. For example: you can change the Data Pipeline any time, but to make changes to the DataFlow you have to take ownership of the item first. Another example: you can move a Data Pipeline from one workspace to another by saving a copy. You cannot do this for a Data Flow, which you first need to export locally. Of course, these are minor inconveniences, but it is things like this that shows that the experience of Fabric is not as seamless and polished as the marketing department likes you to believe. It was frustrating and confusing.
Another confusing aspect of Fabric that I experiences, was the different capacities that exist. *Before I continue, I want to mention that I’m aware that Microsoft is actively working on the simplification of this, but the fact remains that they offer and sell this to customers right now.*Let’s take a look at all the licensing options that are offered as of February 2025:
I know this complexity originates from the history of Fabric. It used to be PowerBI, but what I don’t understand is why the Trial capacity is different from the Fabric capacity. They are the same, with the only difference being that one is paid and the other one isn’t. The reason I think this is a problem, is because one does not simply move away from a Trial capacity. It took me 2 support tickets to figure out how this works, and if you want to know, the problem was that you cannot move items between regions for some reason.
Lastly, we have to talk about Purview. Purview is designated to handle the governance part of the platform. The problem is: Purview is deeply integrated with M365, not so much with Azure, and definitely not with Fabric yet. I have had a lot of headaches about roles and permissions. Let’s say it’s not as seamless of an experience as marketed.
Of course, I’ve not covered every little frustration (such as AI, because of course they had to slap AI on this). This also would not feel fair. I can see Microsoft is really trying, but in my eyes they moved to market too quick with Fabric. I do not understand that of all the features and services that are in public preview for the longest time, this is the one that moved to GA in this stage.
The Ugly
In conclusion, if you expected you were able to migrate all your current data workloads to Fabric from something like Databricks (oh no, he said the word!), you’ll be very disappointed. Although the ideas behind both services are similar, Fabric does not even come close to the capabilities and production readiness of its competitors, yet.
That being said, I do believe Fabric in its current state does have its use-cases. It seems great for moving reporting capabilities closer to their sources, and allowing analysts to own solutions end-to-end. This goes for other contained and decoupled solutions as well. These use-cases are great for implementations of Data Products according to the Data Mesh principles, which Fabric can handle. Especially when the data maturity within a company is not very high, Fabric will find its place: it’s perfectly capable of supporting Proof of Concepts and small products.
But, here comes the ugliness. Ideally, these Proof of Concepts and workloads will develop and grow. This is where I get a little worried. Fabric needs more work before I would trust it to handle realproducts.
Thank you for reading. I’m very curious about your experiences!
Hi, I’m Bastiaan 👋🏼 Founder of datalyft, a small data agency helping companies transform their raw data into real value. I write about the Modern Data Workflow, where I explore tools & processes to supercharge your data capabilities. Follow me for more!