Press "Enter" to skip to content

Category: Microsoft Fabric

Schema Locks and Time Travel in Fabric Data Warehouse

Published 2026-09-10 by Kevin Feasel

Louis Davidson continues a comparative analysis:

When reading that title, you probably want to get to concept of time travel first, because if you could really do that, you wouldn’t have any more backup and recovery problems. The time travel I will cover is about getting to past versions of data in your data warehouse tables. This is done in a similar way to what you can do with temporal tables in SQL Server, but also VERY different.

The schema locks section is a wee bit of a follow on to Part 4 where I covered isolation where I showed how updating data was handled concurrently. In this post I wanted to briefly finish that conversation and note how it works when you have schema locks.

Most of this behavior is similar to what we have in SQL Server on-premises, though time travel does have a couple of nuances to it versus the box product.

Comments closed

Mirroring Data from SQL Server into Microsoft Fabric

Published 2026-09-09 by Kevin Feasel

Greg Low has a guide:

Mirroring in Microsoft Fabric is useful when you need to make SQL Server data available in Fabric. Perhaps in OneLake, for example, if you need to use the data for reporting, analytics, notebooks, or another Fabric workload.

However, it’s not suitable for everything, as I’ll explain in this complete guide to mirroring data from SQL Server to Microsoft Fabric.

Before we get started, a note about compatibility. Since SQL Server 2005, there’s been a type of database mirroring totally unrelated to Microsoft Fabric mirroring. I wish these types of terms weren’t so overloaded but, in this article, when I say mirroring, I’m talking only about Fabric mirroring.

Click through for a FAQ-style introduction.

Comments closed

Implementing SCD Type 2 in Microsoft Fabric

Published 2026-09-08 by Kevin Feasel

Nikola Ilic reminds us that the Kimball model is alive and well:

Slowly Changing Dimensions (SCD) are one of the fundamental concepts in dimensional modeling. If you are not sure what dimensional modeling is, I suggest you first check the series of articles I wrote on data modeling some time ago.

And, when it comes to SCD in particular, SCD Type 2 is rightly considered “the queen” of the SCDs for analytical workloads. Without going into details (since the main goal of this article is to show you HOW to implement the SCD Type 2 in Microsoft Fabric), I’ll just briefly introduce the general concept behind the SCD Type 2.

Click through for a primer and examples in the warehouse and lakehouse.

Comments closed

Spark SQL Temporary Views on Fabric Schema-Enabled Lakehouses

Published 2026-09-03 by Kevin Feasel

Gerhard Brueckl wants to create a temporary view:

Some time ago my friend Christian Henrik Reich blogged about how to handle schema-enabled lakehouses in Spark temporary views. We already found a good solution leveraging SQL USE keyword to set the schema once and reference tables by name only in our views. However, after some tests, in particular with notebookutils.notebook.runMultiple, I realized that there are some more things to consider as suddenly my SQL and notebooks stopped working when executed in parallel!

But let set the scope for this blogpost first. We recently built a data platform on Microsoft Fabric where we integrated data from different source systems which were combined into a single schema-enabled lakehouse where each source system had it own schema. Naturally, when querying those schemas, we used temporary views to express our business logic in SQL and then continue working with PySpark. We relied heavily on USE to work around the issue describe by Henrik until we realized that this approach does not work in combination with runMultiple. So we had to find another solution which I will describe here.

Read on for that solution.

Comments closed

Atomicity and Isolation in Fabric Data Warehouse

Published 2026-09-03 by Kevin Feasel

Louis Davidson receives a surprise:

Ironically, today’s topic is kind of the opposite. I expected things to be far different in Fabric, but it isn’t really that different, at least not in behavior, except when it is. Since this system is Parquet file based, I didn’t think there would be locking, blocking, etc. I sort of expected it would be sort of locked down when writing data, maybe just single threaded per file, but highly concurrent when reading. Reads would most likely work like time travel and read previous data where it existed. And transactions? Would there be transactions? I guessed not before I got started with it.

Was I wrong?

Read on for the answer. The concurrency model isn’t exactly the same as SQL Server’s, but it’s not that far off.

Comments closed

Referencing Assets in Power BI Reports via OneLake URLs

Published 2026-08-31 by Kevin Feasel

Chris Webb wants to load some images:

Several years ago I wrote a very popular blog post about how to store images for your reports inside your Power BI semantic model. It solved the problem of how you could use display images (for example of products) inside your reports without making those images available via a public URL or personal OneDrive Embed Codes. I was very proud of how efficient the M code to do this was but the code was complicated and storing images as text inside a semantic model makes refreshes a lot slower and increases the size of your semantic model in memory, so it’s not ideal. The good news is that, if you have enabled Fabric in your tenant, the August 2026 release of Power BI brings a much better way of solving this problem: you can now store your images (and indeed other files) inside OneLake and reference them from there. This means you can store your images in a secure location, alongside all of your other data, and make them available for use in Power BI. What’s more this doesn’t just work for images, it also works for other types of files such as GeoJSON files used by map visuals.

Click through to see how.

Comments closed

Dynamically Changing Fabric Data Warehouse SQL Pools

Published 2026-08-27 by Kevin Feasel

Gilbert Quevauvilliers saves some money:

After reading about the new SQL Pools feature for Warehouses in Fabric, I had an idea, if I could change the SQL Pool configuration based on the expected query load, I could then consume less capacity and have better performance.

https://learn.microsoft.com/en-us/fabric/data-warehouse/custom-sql-pools

Here is an Example I thought of below.

  • When the ETL load is running optimize the SQL pool for writing as typically data is being inserted.
  • After the ETL load and for the rest of the day, almost all queries are read by the Warehouse, so change the SQL pool to be read optimized.

Click through for a Python notebook that does this.

Comments closed

INFORMATION_SCHEMA and the Fabric Warehouse

Published 2026-08-27 by Kevin Feasel

Louis Davidson bangs his head against a wall:

When we decided to use T-SQL and a Fabric Data Warehouse for our ETL, I started thinking about generating the code with the metadata in the system catalog views or the INFORMATION_SCHEMA. Having done this sort of thing before in SQL Server over the years, it seemed really straightforward. And it kind of is, until it isn’t.

In this blog I want to show you a few ways you need to understand how working with metadata and temp tables varies (sometimes wildly) from the comfortable SQL Server environment and language you know very well, and give tips on how to get around these differences.

Click through for some of the fun you can have with a distributed SQL Server-like product.

Comments closed

What to DO When Out of Capacity in Microsoft Fabric

Published 2026-08-24 by Kevin Feasel

James Serra hits the ceiling:

Microsoft Fabric makes it wonderfully easy to put many analytics workloads on one platform. Power BI, data engineering, warehousing, data science, real-time analytics, Copilot, and other experiences can all share the same Fabric capacity. That is a big advantage, but it also creates an architectural question that does not get much attention until something goes wrong: what should you actually do when a capacity starts running out of room? The answer is not always “buy a bigger capacity.” Sometimes you should optimize, sometimes scale up, sometimes scale out, and sometimes isolate the workload causing the problem.

Read on for an explanation of what it means to “run out of capacity” and a quick overview of four options available to you.

Comments closed

The Pain of Microsoft Fabric Deployment Pipelines

Published 2026-08-24 by Kevin Feasel

Meagan Longoria has a list:

Fabric deployment pipelines look like they solve CI/CD for Fabric content, especially for people who prefer a GUI over writing code to handle deployments, but the implementation has enough structural gaps that they fall apart for several real deployment workflows. Even when they do work, the UI isn’t always intuitive.

Every piece of active software carries a backlog of feature requests and known limitations, and deployment pipelines get new capabilities on a regular basis. Everything below reflects how deployment pipelines behave as of August 2026. Some of it may have changed by the time you’re reading this, so check Microsoft’s docs for the current state before you plan around any of these.

Click through for the list, as well as a few alternatives that come with their own trade-offs.

Comments closed