Press "Enter" to skip to content

Category: Microsoft Fabric

Saving Unity Catalog Tables in Microsoft OneLake

Gerhard Brueckl pushes boundaries:

Microsoft and Databricks recently announced the next step of their collaboration and integration. It is now possible to store Databricks Unity Catalog tables directly in Microsoft OneLake. Here are the official announcement from Microsoft: https://community.fabric.microsoft.com/t5/Fabric-Updates-Blog/Extending-interoperability-Azure-Databricks-can-now-store-Unity/ba-p/5199741

Both parties have been working together to make this possible: Microsoft introduced the new item type Azure Databricks Storage and Databricks added support for OneLake for Unity Catalog External Locations (which can then be used to store the actual data). The UC External Location would then simply point to the storage endpoint provided by the Azure Databricks Storage item in Microsoft Fabric.

Click through to see what Gerhard found, as well as the results of some experimentation.

Leave a Comment

Fabric Warehouse CU Metering and Workloads

Nikola Ilic digs into the numbers:

If you are using Microsoft Fabric, you’ve probably received the same email notification as me:)

I’m talking about the one about Fabric Data Warehouse and SQL analytics endpoint metering.

Starting in August 2026, Warehouse CU consumption is moving away from the current per-query CPU-time model and toward a per-workspace, virtual-node time model.

Read on to see what will change and how that should affect the way you think about this infrastructure.

Leave a Comment

Downtime Woes and Microsoft Fabric

Joey D’Antoni describes a problem:

All that being said, customers buy online services and expect them to be available. One of the reasons a company chooses Fabric, Databricks, or Snowflake is the notion that those platforms for Spark and various data warehousing options will be secured, patched, and better maintained than a non-technology company could do by simply deploying Spark into Kubernetes or VMware. With that, the cloud providers have an obligation to deliver services to their customers, and deliver availability and performance congruent with their pricing.

One of the things I expect from a cloud provider is honest post-mortems when they have an outage, and maintaining a history of their outages. These histories help architects better design systems, as we can better identify weaknesses in various cloud services that we might want to design around. Azure and AWS both do an excellent job of providing detailed information around “what happened” in incidents.

But as Joey mentions, Microsoft Fabric doesn’t have the same information. It also doesn’t have a dedicated SLA. But it does have a series of outages over the past month.

Leave a Comment

In Defense of DirectQuery

Chris Webb lays out an argument:

For as long as I’ve been using Power BI – which has been from the beginning – the advice about which storage mode to choose has been the same: use Import mode unless you have a really, really good reason to use DirectQuery mode and even then you’re probably wrong and should use Import mode. Import mode was always a lot faster and a lot easier to tune. Marco’s advice in this LinkedIn post from last year pretty much summed up my attitude and that of every other Power BI expert out there:

Click through for Chris’s argument. As a side note, I saw Conor Cunningham present a session this past weekend at SQL Saturday Austin on the GPU acceleration that Chris mentions in the Fabric Data Warehouse, and under certain circumstances (think “classic Kimball model”), it results in a 2-10x performance improvement, with the expectation somewhere around 3-5x. In other words, a query that takes 50 seconds to run and makes sense to run on GPU drops down to about 10 seconds with no development effort. For well-designed semantic models, this might be a significant factor that pushes the trade-off rubric in the direction of DirectQuery versus Import or DirectLake.

Leave a Comment

Trusting Outputs from Fabric Data Agents

Jens Vestergaard says don’t trust, do verify:

In two previous posts I went down the path of getting a semantic model ready for AI: descriptions on every measure, an instructions file, the schema tidied up enough that a Fabric data agent has something real to read. That work has a satisfying endpoint. The model looks ready.

Ready is not the same as right.

The kind of evaluation Jens is talking about is fundamental to good business intelligence practices, regardless of whether you throw language models into the mix. Where language models do add complexity is the arbitrary scope of questions, how ambiguous people tend to be when writing, and the stochastic nature of answers. All of that makes the problem harder, though at least it isn’t an entirely different class of problem to solve.

Leave a Comment

Thoughts on Deploying Fabric Data Agents

Marc Lelijveld performs a deployment:

Over the past year, I’ve frequently blogged about Fabric Data Agents. Alongside myself, many other community members have been sharing their experiences and best practices to get the most out of Data Agents. However, there is one topic I rarely see discussed: deployment of Data Agents.

As Data Agents become part of production-grade solutions, deployment and lifecycle management become increasingly important. Building a Data Agent is one thing, but moving it consistently between Development, Test, and Production environments is a completely different challenge.

In this blog, I will share my current best practices around deploying Fabric Data Agents, including what works today, where the limitations are, and the gaps that still exist.

Read on to see what Marc recommends at this time, with the proviso that some of this will likely change as the product develops further.

Leave a Comment

Implementing IoT-Style Data in Microsoft Fabric

Hristo Hristov takes us through a walkthrough:

Hardware sensors or diverse types of equipment can generate IoT data at a high frequency, e.g., every second. Additionally, IoT data can be messy, semi-structured or just have huge volume and many disparate sources. How to ingest and model IoT data in Microsoft Fabric using the medallion lakehouse architecture?

As I was reading through this, the thing that kept coming to my mind is, if we’re really working with device data at a fairly high periodic frequency (e.g., once a minute or more often), this is probably a job for the Eventhouse and KQL. Though if your devices either don’t collect push information more frequently than, say, hourly, this approach is probably fine.

Leave a Comment

Major Announcements from Microsoft Build 2026

James Serra puts together a list:

Once again there were a number of Microsoft Build announcements related to data and AI, and some were very impressive. Below are my favorites. I am prioritizing the data announcements first, because that is where my brain naturally goes (and because AI without good data is just a very confident intern with access to a keyboard).

The biggest announcements across Microsoft Fabric and databases can be found in the Microsoft Build 2026: Building agentic apps with Microsoft Fabric and Microsoft Databases blog post.

This looks like another year of Fabric + AI as the (almost) entire data platform focus at Build.

Leave a Comment

Fabric Data Agents and Power BI Row-Level Security

Jens Vestergaard digs into a security challenge:

In the last post I walked through auditing a semantic model before connecting it to an AI tool like Fabric Data Agent. Descriptions, naming, explicit measures, star schema: the things that decide whether a Fabric data agent generates an accurate query or a confident wrong one. I left one thing out on purpose, because it deserved its own post and because I got it wrong the first time I thought about it.

Security.

Click through for a few subtle security issues that automated agents can expose. It turns out to be a lot more challenging than you may first expect, just as Jens discovered.

Leave a Comment

Variable Libraries in Microsoft Fabric

Nikola Ilic digs into a feature:

I hear you, I hear you: Nikola, that’s what deployment rules in Fabric Deployment Pipelines are for, isn’t it? Well, partly. But there’s a Fabric item built specifically to put an end to this whole genre of pain, and it’s the variable library. This article is the long version: what it is, how it’s wired together under the hood, who can actually consume it, when you should reach for it, when you absolutely shouldn’t, how it compares to the other parameterization features in Fabric, and a real telco demo to make it all concrete.

Click through for a deep dive into how it works.

Leave a Comment