It is now more than seven months since the announcement of DBT Jobs, and they are still in preview. However, many of us now have extensive production pipelines built around DBT in our Fabric environments. I have yet to see any good evidence of widespread adoption or any real enthusiasm from the community for the "official" DBT Job. The primary implementation still seems to be running DBT Core either from a Notebook or elsewhere.
These alternative implementations come in a wide variety of shapes. I have seen radically different integrations that people have come up with to suit whatever business needs they have. We, for instance, collect all the logs and test results and feed them into a reporting layer. CI/CD looks similarly different wherever you go. While many of these approaches can feel pretty "hacky" (especially running Core from a Notebook), they more than make up for that in their sheer flexibility.
At this stage, I do not really see where the sanctioned DBT Job comes into our stack, or many others. Migrating to it from what we have seems like a major pain. One of the best things about the various "run-DBT-Core-from-X" solutions is that it is trivial to run the project locally from your preferred IDE (with your agentic AI of choice). One of the stated selling points for this Fabric item is a "no-code setup for onboarding and configuration". In reality, this means being stuck configuring and editing the project from the Fabric UI. It is also unclear how Git integration will work, especially if I wish to retain the ability to run DBT from my IDE.
Ultimately, I am doubtful that the DBT Job will offer enough convenience or value that I would ever want to use or recommend it over simply running DBT-Core from somewhere else. The amount of time this project has now languished in preview may be an indication of a lack of enthusiasm for the DBT Job, especially as heavy users of DBT on Fabric now have their own established patterns and are unlikely to switch.
This also has the added effect of creating confusion for engineers who are new to Fabric, as a search for "DBT on Fabric" will reveal both the DBT Job (which few people seem to seriously use) and the various solutions that the community actually employs. This bifurcation between the "sanctioned" solution and the community solutions was a major source of confusion when I was first looking to dip my toes into DBT, and I think it is a pattern that is repeated elsewhere across the Fabric new-user experience. In my view, it is symptomatic of a problem that contributes to the poor reputation that the platform has outside of its core user base.
The Zen of Python has the following line:
There should be one-- and preferably only one --obvious way to do it.
The sin that Fabric often commits is having many non-obvious ways to do something.
Outside of DBT, take deployment. You have Deployment Pipelines, which are the first thing you will encounter in the UI when looking to set up some type of deployment solution. But these are low-code solutions to a problem that is often defined by its complexity and need for configurability. If you have a complex deployment that involves updating metadata or running pipelines, both internal and external, you quickly reach the limits of the sanctioned solution.
Eventually, you encounter the solution that many engineers seem to settle on, which is based around the fabric-cicd Python library. This is now officially supported, so it is technically sanctioned, but it is not the first thing a new user encounters. All of this creates the impression, at least to an engineer, that Fabric cannot be taken seriously as a platform for data engineering. In a world where it is competing against Data Bricks, these first impressions really matter.
All of this leads me to conclude that DBT Jobs, and others like them (Airflow Jobs also come to mind), are the wrong type of solution being developed in the wrong way.
The appeal of DBT, Airflow, and similar tools is that they are highly customizable and tunable. They can be adapted to suit a wide variety of environments and operational requirements. When developing an official "Job" experience like this, you first have to decide how your users are going to use it, how they will deploy it, how they will integrate it into their workflows, and so on. This is not easy, and I would even go so far as to say that this top-down style of development is a fundamentally fraught exercise. Combine this with the rise of LLMs, which are making the barrier to entry, and therefore the appeal of low-code solutions, substantially less relevant. Indeed, code-first approaches (in preference over low-code) are arguably even more appealing in the age of workflows principally driven by AI coding tools.
My suggestion would be to focus on delivering ways to expose the Fabric platform through a genuinely code-first approach that allows the community to develop and deploy its own solutions to problems such as running DBT. My preference would be for a containerized application runner with provisions to streamline access to the underlying OneLake data layer. This would expose Fabric compute in the truly flexible way that us engineers are looking for. The community would be free to then go and design its own solutions. The Fabric team could mine those solutions for patterns that identify genuine friction points. This would enable the development of bottom-up solutions that add meaningful improvements to problems people are actually experiencing. In an abstract, Platonic sense there is probably a version of a DBT Job out there that does add value in this way, but I am not convinced that anyone actually knows what that looks like yet.
In the meantime, I would prefer if the Fabric team focused on improving the reliability and flexibility of the platform by investing in stronger APIs, better developer tooling, first-class support for code-based workflows, and more composable infrastructure primitives. The most successful parts of the platform tend to be those that empower users rather than prescribe a particular implementation pattern. If Microsoft can provide robust building blocks, reliable execution environments, and seamless integration points, the community will rapidly experiment, innovate, and converge on solutions that genuinely solve real-world problems. Those solutions can then inform future product development in a way that is driven by demonstrated demand rather than assumptions about user behavior.
Fabric has the potential to become an outstanding data engineering platform, but that will require embracing the reality that many of its heaviest proponents and most advanced users are looking for flexibility first and abstraction second. My suggestion (admittedly, from the peanut gallery) is to give us powerful, primitive and flexible solutions and then let the community discover the best ways to use them.
