Press "Enter" to skip to content

Category: Microsoft Fabric

Deleting Default Semantic Models in Microsoft Fabric

Pradeep Srikakolapu says good riddance:

In our earlier announcement, we shared that newly created data warehouses, lakehouses and other items in Microsoft Fabric would no longer automatically generate default semantic models. This change allows customers to have more control over their modeling experience and to explicitly choose when and how to create semantic models.

Starting November 20, 2025, Power BI *default* semantic models are disconnected from their item and become independent semantic models.

Click through for an overview of those changes and how you can get rid of the default models you may still have hanging around.

Comments closed

Azure Tenants and Microsoft Fabric

Andy Cutler begins a new series on Microsoft Fabric architecture:

Our Fabric Architecture journey starts with Azure Tenants (the kick-off blog in this series is here with a few jumping-off links to get started with thinking about Fabric Architecture). If you’re ready to spent time sketching out your Fabric Capacity planning, workspace strategy, domain topology, lakehouse/warehouse creation, data loading processes…you might want to stop for a minute and think about tenants. The question I’d like you to consider is What do I need to know when working with a single or a multi-tenancy approach? Let’s unpack this question because while it might sound like a simple list, it actually shapes your governance, scalability, and Fabric operational model. If you’re a seasoned Azure Architect veteran then you already know how to decide between single and multi-tenant cloud rollouts (also, please comment if you have anything to add please), if you work with Fabric/Data and don’t really dive into Azure architecture on a daily basis then please stick around. Hopefully this blog gets you thinking about single/multi-tenant architectures and the benefits/costs.

Read on for a dive into what tenants are, the benefits of single- versus multi-tenancy, and how it all ties into Fabric.

Comments closed

Generating an Entity Diagram in a Fabric Eventhouse

Guy Reginiano announces a new tool:

As your KQL database grows, tables gather data from several Eventstreams, functions connect different tables, update policies move and transform data, and materialized views quietly keep aggregated data up to date – all working together behind the scenes 

It’s powerful, but it can also be hard to see the full picture. 

That’s exactly why we built the Entity Diagram – to give you a simple, visual way to explore how everything in your database connects.

Click through to see how it works.

Comments closed

Microsoft Fabric October 2025 Feature Summary

Adam Saxton has a list:

This month’s update delivers key advancements across Microsoft Fabric, including enhanced security with Outbound Access Protection and Workspace-Level Private Link, smarter data engineering features like Adaptive Target File Size, and new integrations such as Data Agent in Lakehouse. Together, these improvements streamline workflows and strengthen data governance for users.

The list doesn’t feel quite as long as the prior couple of months, but there’s still a lot of content on here.

Comments closed

OneLake Security and the Fabric SQL Analytics Endpoint

Freddy Santos takes us through the latest with respect to security in OneLake:

OneLake Security centralizes fine-grained data access for Microsoft Fabric data items and enforces it consistently across engines.
Currently in Preview and opt-in per item, it lets you define roles over tables or folders and optionally add Row-Level Security (RLS) and Column-Level Security (CLS) policies. These definitions govern what users can see across Fabric experiences.

Read on to see what you can do.

Comments closed

Microsoft Fabric Direct Lake Join Index Creation

Phil Seamark explains a recent change:

If you’ve been working with Direct Lake in Microsoft Fabric, you’ll know its magic resides in its ability to quickly load data. It loads data into semantic models from OneLake when needed. This feature eliminates the overhead of importing. But until recently, the first query on a cold cache might feel sluggish. Why? One reason for this is that Direct Lake must build a join index. This index is added to the model during the first query. This index is a critical structure that maps relationships between tables for efficient lookups.

Earlier, this process was single-threaded and slow, especially on large tables with high cardinality. The good news? That’s changed.

Read on to see how, what a join index is, and what this impact looks like in practice.

Comments closed