Press "Enter" to skip to content

Category: Microsoft Fabric

Clustering in Fabric Data Warehouse

Louis Davidson does some exploring:

Clustering is one of the data terms that could not have been created by a database design person. Why? Because it has multiple meanings. In PostgreSQL it means the same thing as an instance in SQL Server. In server architecture it means connecting multiple servers together to form a “single” unit of some form to protect against failure. Then it means an index that determines the physical storage of a table in some manner. This usage of the word means the former.

The weirdest part of using a Fabric Data Warehouse when you first try to look at a query is the lack of indexes. So (currently as of writing this is late 2026), you only have this one tool to affect your performance. The tool allows you to order the data physically in your files so query processing can be reduced when searching the physical file.

Read on for an introduction of how it works, with the caveat that Louis is about two pages ahead of most people in the book.

Leave a Comment

Tracking Microsoft Fabric Capacity Operation Events

Gilbert Quevauvilliers stores some data:

This blog post will explain how to capture the data from real-time events for Fabric Operation Events and store the results in a Lakehouse.

My approach is to use a Python notebook to query Eventhouse.

The reason for this is the Python notebook runs very quickly and because it consumes very little Capacity Units, it is a very efficient way to store the Fabric Operational Events to be analyzed over a long period of time.

Read on for the instructions and the notebook that Gilbert used.

Leave a Comment

An Explanation of Fabric Licensing

Paul Turley digs in:

When the Power BI cloud service morphed into the Fabric platform a few years ago, Microsoft introduced very attractive cost and capacity options for small organizations, teams and projects – and its easy to scale-up. This is why Fabric works for both small and huge workloads.

Fabric licensing might look intimidating from the outside, mostly because Microsoft describes it in acronyms. Strip those away and it really boils down to two questions.

Click through for those questions and what it all means.

Leave a Comment

Creating Alerts in Microsoft Fabric

Koen Verbeeck turns on the Bat-signal:

We are building a new data platform with Microsoft Fabric and we’re using the warehouse for our “gold layer”. We don’t have real-time ingestion or analytic requirements, but we have a use case where we want to send an alert if a certain threshold is reached. Ideally, the alert is sent when a SQL query returns a result set.

Click through to see how that’s possible, as well as what kinds of rules, triggers, and conditions you can set.

Leave a Comment

Shortcuts to Iceberg Tables in Microsoft Fabric

Teo Lachev makes a connection:

Snowflake is an increasingly popular option for data warehousing. One nice Snowflake feature is the ability to configure a table to save its data in Iceberg file format in the Snowflake own managed storage or external storage, including S3, GCS, ADLS Gen 2, and OneLake. As I wrote in the post “Give Me Your Data!”, Fabric supports shortcuts to Iceberg tables, in which case the data is not copied but exposed as a Parquet Delta table in a Fabric lakehouse. This could be useful when building Fabric-centric solutions on top of Snowflake without moving the data.

Iceberg isn’t just a Snowflake thing, though this is certainly helpful if you do have both Snowflake and Fabric.

Leave a Comment

Configuring Row-Level Security with OneLake Security

Reza Rad secures some data:

If you’ve set up row level security in Power BI before, you know the usual drill: open the semantic model, add a role, write a DAX filter. But once your data lives inside a Microsoft Fabric OneLake structure, there’s a better way to do this. You can implement it directly in OneLake instead, so that every object built on top of that data, your lakehouse, your SQL analytics endpoint, your semantic model, and your report, all follow the same security setup automatically. Define it once, upstream, and everything downstream inherits it. This is called OneLake security, and in this post I’ll walk through exactly how to set up row level security (RLS) this way, from the lakehouse all the way to your Power BI report.

Read on for a video and summary with timestamps.

Leave a Comment

Setting Fabric Connection Properties with the ODBC Driver

Ryan Adams digs into configuration settings:

Some SQL Server ingestion scenarios depend on connection-string properties that the built-in SQL Server connector in Data Factory for Microsoft Fabric doesn’t expose. If you need to route reads to an Availability Group secondary, connect reliably across a multi-subnet listener, or read columns protected by Always Encrypted, you’ve probably hit that wall. This post shows a supported way around it: use the ODBC connector together with an ODBC data source name (DSN) configured on an on-premises data gateway (OPDG). The example in this post uses Always Encrypted in a Copy job.

Click through to see some of the things you can set. These are standard SQL Server properties, so they can also work with normal SQL Server installations that are making use of Availability Groups and Always Encrypted.

Leave a Comment

Connection Recency in Fabric REST APIs

Ryan Adams explains a concept:

Connections are shared infrastructure in Microsoft Fabric. Pipelines, dataflows, semantic models, and other Fabric items use them to reach data sources without storing connection details and credentials in every item. Connection Recency adds the context administrators need to understand how each connection is being used. If you go to “Manage Connections and Gateways” in Fabric settings and open the settings of any connection, the following information card will populate:

Click through to learn more about connection recency and how it can be helpful to understand the mechanic.

Comments closed

CU Consumption after the Query Finishes

Nikola Ilic answers a question:

After my article on Fabric Warehouse CU metering, which caused a lot of people reaching out and mentioning that it helped them understand the topic better, I decided to cover SQL database in Fabric from a similar angle too.

Imagine opening an internal application, updating a few records, and closing it two minutes later. You check consumption afterward and see that compute continued accruing.

Before blaming the application, it helps to understand what keeps the database online, and what Fabric actually measures.

Read on for that answer.

Comments closed

A Review of SQL Database in Microsoft Fabric

Paul Turley shares some thoughts:

When I first learned that SQL Server databases were coming to Fabric, I wasn’t entirely sure how and why we would use it. Now that I’ve had a chance to use SQL Database in Fabric, I wanted to share some of my experience and thoughts about where and how it makes sense to use it. I thought: Fabric is an analytics platform, and we primarily store data in a Lakehouse or warehouse to prep it up for reporting and analysis with Power BI. Why would I want to store data in a SQL Server database in the Fabric SaaS environment? I’ve since implemented “SQL Database for Fabric” (aka “Fabric SQL Database”) in several projects and I’m just blown away by how fast and simple it is to use. In this post, I will dig into the cost and performance and use cases where this option makes the most sense compared to other hosted implementations of the SQL Server database engine.

Click though to learn more.

Comments closed