Press "Enter" to skip to content

Category: Microsoft Fabric

Direct Lake Mode Benefits in Power BI

Published 2026-07-13 by Kevin Feasel

Chris Webb lays out the pros:

This is a blog post I’ve been meaning to write for a long time. Since Fabric launched there has been a lot of focus on Direct Lake mode in Power BI and a lot of people used it because it was the cool new thing. Arguably, we at Microsoft have been guilty of telling people to use it because it was the cool new thing without properly explaining what the benefits are of using it. Direct Lake doesn’t completely replace other storage modes: in a recent post I talked about when Import/DirectQuery composite models are the best choice; Marco wrote a good article on Direct Lake vs Import mode which makes the case for the continuing relevance of Import mode for many scenarios. So what are the main benefits of using Direct Lake mode? 

Click through for Chris’s answer.

Comments closed

Performing a Lakehouse Table Health Check

Published 2026-07-13 by Kevin Feasel

Jon Lunn looks at a stored procedure:

Microsoft have rolled out a new ‘sys’ stored procedure called ‘sys.sp_get_table_health_metrics’ for checking the health of your tables in your Lakehouse. And it outputs a lot of metrics looking at the state of your table and anomaly detection in them.

What does it check for?

Click through for that answer, as well as some of the things you should watch for in the procedure results, and what you can do if it does catch something.

Comments closed

Merging Data into a Fabric Lakehouse via Python Notebook

Published 2026-07-10 by Kevin Feasel

GIlbert Quevauvilliers uses a pure Python notebook:

In this blog post I am going to show you how to use a Fabric Python runtime notebook (This is the notebook which only uses Pure Python functions and consumes significantly lower Capacity Units (CUs)).

The pattern is how to get new data and merge it into an existing Lakehouse table. This ensures that if the notebook is run again data will not be duplicated.

Why I am sharing this is I have found that there is not a lot of useful information about how to use a Python notebook to write to a lakehouse table easily. And then also how to use a Merge statement making it easier to insert or update your lakehouse tables. This simplifies the ingestion process, runs faster and consumes the least amount of CUs

Gilbert doesn’t mention it in the blog post but the notebook does use DuckDB to query the data using SQL.

Comments closed

A Primer on Microsoft Fabric for SQL Server Professionals

Published 2026-07-07 by Kevin Feasel

Kevin Chant gives the low-down on Microsoft Fabric:

This post covers how you can spread your SQL Server wings with Microsoft Fabric in 2026. As part of a long-running series of posts about spreading your SQL Server wings with the Microsoft Intelligent Data Platform.

Just after Microsoft Fabric was publicly announced during Microsoft Build 2023, I published a post that covered spreading your SQL Server wings with Microsoft Fabric.

A lot has changed since then. Including Microsoft Fabric becoming generally available and the introduction of more workloads. Since Data Days is currently taking place, I decided to publish an updated version.

There’s a lot that has changed in the product, meaning that if your experience with it was how it looked in early 2024, it’s a different world now.

Comments closed

A Primer on OneLake Security

Published 2026-07-07 by Kevin Feasel

James Serra takes us through the different security models in Microsoft Fabric:

The idea behind Fabric OneLake Security (which GA’d on April 2026) is to centralize data access controls at the data layer, rather than configuring security separately for every Fabric experience. You define security once, close to the data in OneLake, using roles that can control access at the folder, table/object, row, and column levels through object-level security (also called Table-level and folder-level security), row-level security (RLS), and column-level security (CLS). Those rules are then enforced by supported Fabric engines and access paths, such as Lakehouse, Spark notebooks, the SQL analytics endpoint in user identity mode, and Power BI Direct Lake semantic models. Downstream experiences that go through those governed paths, such as Power BI reports or Excel connected through the semantic model, inherit the same secured view of the data.

However, OneLake security is not the native security model for every data location in Fabric.

Read on to see which components use what security models, as well as some hints as to the vision for Microsoft Fabric’s ultimate security model.

Comments closed

Ways Data Apps Improve Microsoft Fabric Semantic Models

Published 2026-07-06 by Kevin Feasel

Ruben Van de Voorde digs into data apps:

Fabric data apps are the most interesting thing to happen to data visualization in Power BI and Microsoft Fabric, ever. They provide limitless potential for how to visualize and interact with your data. However, they also indirectly provide a major benefit to your semantic models by allowing them to be simpler to build, use, and maintain.

In this article, we argue that data apps provide a reporting layer that is separate from the semantic layer, something that wasn’t true in Power BI due to tight coupling between reports and semantic models.

Click through to see where they fit vis-a-vis Power BI reports and semantic models.

Comments closed

Building a Lakehouse Table Health Pipeline

Published 2026-07-02 by Kevin Feasel

Gilbert Quevauvilliers builds a pipeline:

In this post I will show how I used GitHub Copilot CLI / Agent mode in VS Code to create a Microsoft Fabric pipeline that checks Lakehouse table health and only optimizes tables that require maintenance. I’ll also show the prompts I used, the issues I ran into, and how Copilot helped me resolve them.

Recently Microsoft announced Lakehouse table health. The post showed how you can check can check the health of your Lakehouse table in a very simple way.

Read on to see what this feature can do, as well as how Gilbert was able to gin up (with the help of GitHub Copilot) a pipeline to optimize lakehouse tables. What I appreciate is that Gilbert also included the errors in the process, rather than making it seem like everything with perfectly the first time around.

Comments closed

Saving Unity Catalog Tables in Microsoft OneLake

Published 2026-07-01 by Kevin Feasel

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.

Comments closed

Fabric Warehouse CU Metering and Workloads

Published 2026-07-01 by Kevin Feasel

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.

Comments closed

Downtime Woes and Microsoft Fabric

Published 2026-06-29 by Kevin Feasel

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.

Comments closed