The image displays a computer screen with a pop-up message indicating that Fabric access is required to export query results. It informs the user that their "My Workspace" is not assigned to Fabric and offers options to assign it or enable a Fabric trial.

Hey #microsoft #PowerBI peeps, WTF is this all about?

Excuse the poor picture quality - didn’t want to log into my social media on my work laptop 🤷‍♂️

I had this on my bucket list for a while. This year I am submitting a session with the name "What Retro Games Taught Me About Microsoft Fabric", where I will be talking about this a lot :D #MSFabric

Workspace Sprawl Isn’t Your Fabric Problem—Stale Workspaces Are “Do we really need another workspace?” If you’ve built anything meaningful in Microsoft Fabric, you’ve heard some version of that question. It usually comes wrapped in a familiar anxiety: workspace sprawl. Too many containers. Too much to govern. Too hard to manage. Here’s the reframing that matters: workspace count is rarely the risk. The real risk is stale workspaces and stale data—the forgotten corners of your tenant where ownership is unclear, permissions linger, and the platform quietly accumulates operational and compliance debt. In this post I’ll walk through why “workspace sprawl” is a false fear, why workspaces naturally form clusters (and why good development multiplies them), and how intentional permissioning in Microsoft Entra and Fabric keeps management from becoming a linear slog—especially once you introduce automation and tooling.

“#WorkspaceSprawl” in #MSFabric is mostly a myth. The real risk is stale workspaces: unclear ownership, lingering access, and old data that never dies. If your #Governance model still scales linearly with workspaces, it’s time to shift, so you can take advantage of the power of #workspaces.

Stop Paying Hot-Tier Prices for Cold Data: Using ADLS Gen2 to Tame Fabric Ingestion Storage Costs If you’ve been living in Microsoft Fabric for a few months, you’ve probably felt it: the platform makes it incredibly easy to ingest data… and surprisingly easy to rack up storage spend while you’re doing it (especially considering how much storage is included). The pattern is common. A team starts with a Lakehouse, adds Pipelines or Dataflows Gen2 for ingestion, follows a sensible medallion approach, and before long they’re keeping “just in case” raw files, repeated snapshots, and long-running history inside OneLake—often at the same performance tier as yesterday’s data.

#MSFabric storage got expensive? You’re not alone. The fix usually isn’t “delete data”—it’s separating #Archives from analytics storage. In this deep dive, I walk through how to use ADLS Gen2 + #OneLake shortcuts + trusted workspace access to cut storage bloat while keeping Fabric workflows intact.

The Advanced Lakehouse Data Product: Shortcuts In, Materialized Views Through, Versioned Schemas Out There’s a familiar tension in modern analytics: teams want data products that are easy to discover and safe to consume, but they also want to move fast—often faster than the governance model can tolerate. In Microsoft Fabric, that tension frequently shows up as a perception of workspace sprawl. A “single product per workspace” model is clean on paper—strong boundaries, tidy ownership, straightforward promotion—but it can quickly turn into dozens (or hundreds) of workspaces to curate, secure, and operate. This post proposes a different pattern—an advanced lakehouse approach that treats the lakehouse itself like a product factory:

A “workspace per data product” sounds clean—until you have 60 #DataProducts. This advanced lakehouse pattern uses shortcuts + #MaterializedLakeViews + versioned schemas to deliver left-shifted data products with #OneLakeSecurity, while keeping the perception of #MSFabric sprawl under control.

Freeze-and-Squash: Turning Snapshot Tables into a Versioned Change Feed with Fabric Materialized Lake Views Periodic snapshots are a gift and a curse. They’re a gift because they’re easy to land: each load is a complete “as-of” picture, and ingestion rarely needs fancy orchestration. They’re a curse because the moment you want history with meaning—a clean versioned change feed, a Type 2 dimension, a Data Vault satellite—you’re suddenly writing heavy window logic, MERGEs, and stateful pipelines that are harder to reason about than the business problem you were trying to solve. This post describes a Fabric Materialized Lake View (MLV) pattern that “squashes” a rolling set of snapshot tables down into a bounded, versioned change feed by pairing a chain of MLVs with a periodically refreshed frozen table.

#DataSnapshots don’t have to doom you to heavy MERGEs or unbounded refreshes. This #MSFabric #MLV “freeze-and-squash” pattern turns periodic snapshots into a bounded, reusable change feed that can drive both Type 2 dimensions and #DataVault artifacts —without abandoning an MLV-forward architecture.

Ship Your Lakehouse Like Code: Deploying MLVs with a SQL-Only Configuration Notebook If you’re building with Materialized Lake Views (MLVs), you’ve probably felt the tension: the definitions live in code, but the Lakehouse itself is an environment-specific artifact. That gap is where deployments get messy—schemas drift, tables don’t exist yet, and MLV refresh behavior looks “random” when it’s really just reacting to configuration. This post lays out a pattern that closes that gap cleanly: a lakehouse configuration notebook that you promote through your deployment pipeline and run in every environment to create schemas, tables, and MLVs idempotently—using SQL cells only. The key is that MLVs are treated as “definition-driven assets” that can be iterated in dev and re-stamped into test/prod with the same notebook.

Want your #MSFabric #MaterializedLakeView deployments to stop being “it worked in dev” stories? Treat your #Lakehouse like code: one SQL-only configuration notebook, promoted through your pipeline, idempotent in every environment—with CDF set intentionally in the final cell.

Implementing End2End Data Engineering w. Medallion Architecture by Idira Bandari, Fri, Jan 16, 2026, 5:00 PM | Meetup In this hands-on session, we will decode the Medallion Architecture and show you exactly how leading data teams use it to create reliable data lakes and lakehouses. You'll

Indira Bandari is speaking at Data TGIF today! Join us for free online via MS Teams in about 30 mins!

www.meetup.com/data-tgif/ev...

#microsoftFabric #msFabric #dataEngineering #dataScience #dataArchitecture

Delta First: Building Efficient Bitemporal Tables in Microsoft Fabric In financial services, the questions that matter most are rarely answered by “the latest record.” Regulators, auditors, model validators, and operations teams want something more specific: what was true for the business at the time, and what did we know at the time? That’s bitemporal thinking—and it’s exactly the kind of problem where Microsoft Fabric’s Lakehouse on Delta becomes more than storage. It becomes a practical design advantage. In this post, I’m going to walk through what bitemporal tables actually require, why intervals matter (ValidFrom/ValidTo), and how to implement bitemporal efficiently in Fabric by leaning into #DeltaLake in the Lakehouse.

#Bitemporal isn’t extra history—it’s operational clarity: what was true, and what did we know, at the time. Here’s why #MSFabric Lakehouse on Delta is a powerful bitemporal implementation, plus how materialized lake views can own interval closure and when #AzureSQL belongs in the mix. #MSFabric

Two Flavors of DirectLake: Over SQL vs. Over OneLake (and How to Switch Without Surprises) DirectLake has a way of sounding wonderfully simple: “Power BI, but it reads the lake directly.” Then you build two semantic models that both say DirectLake, and they behave… differently. One falls back to DirectQuery when you least expect it. Another refuses to touch your SQL views. Security works for you, but not for your report consumers. Suddenly, “DirectLake” feels less like a feature and more like a riddle. The good news: this is explainable. And once you understand the two flavors—DirectLake over SQL and DirectLake over OneLake…

#DirectLake isn’t “one mode,”it’s two. If your #MSFabric #PowerBI semantic model is slow, failing security tests, or behaving inconsistently, there’s a good chance you’re running the wrong DirectLake flavor (or falling back without realizing it).

Using Variable Libraries in Fabric Notebooks! See a demo here #notebooks #variablelibrary #variableception #msfabric youtu.be/tKgFomg8H44?... via @YouTube

From Tables to Meaning: A Deep Dive into Microsoft Fabric IQ’s Ontology (Preview) AI agents don’t fail for lack of data—they fail for lack of meaning. Microsoft Fabric IQ’s new ontology capability tackles that head‑on by modeling the business concepts, relationships, and rules that live across your estate, then binding them to live data so agents (and people) can ask better questions and take smarter action.

#Agents don’t just need more data—they need shared meaning. #MSFabric #FabricIQ's new #Ontology feature models your business concepts, binds them to live sources, and powers agents that can reason and act.

SAP Business Data Cloud Connect for Microsoft Fabric: The New Backbone of Your Data‑Product Strategy SAP and Microsoft have just taken away one of the biggest excuses for slow analytics and AI on SAP: “We can’t move that data safely or reliably enough.” At Microsoft Ignite 2025, they announced SAP Business Data Cloud (BDC) Connect for Microsoft Fabric—a new capability that lets you share SAP Business Data Cloud data products and Microsoft Fabric data sets bi‑directionally, with zero‑copy, and have those products show up natively in OneLake and back in BDC.

With #SAP #BusinessDataCloud Connect for #MSFabric, you can bring SAP #DataProducts into OneLake—and send Fabric insights back into SAP—bi‑directionally and zero‑copy. Add SAP Databricks, Azure Databricks, and Purview data products, and you have a practical, multi‑platform data‑product estate

Secrets in Fabric: The Breaches That Prove Why Keys Don’t Belong—And How Workspace Identity Fixes It Credentials embedded in Fabric items (notebooks, dataflows, pipelines, semantic models) are a design flaw; three recognizable incidents that show how secrets leak at scale (though none involved Fabric); and the Fabric‑native path forward—Workspace Identity by default, Azure Key Vault references when you must use a secret, and connections that keep CI/CD boring and secure. The pattern behind the big breaches (and the Fabric takeaway)

Hard‑coding #secrets isn’t scrappy—it’s reckless. When huge data can leak from one SAS URL, the only sane default in #MSFabric is Workspace Identity, with Key Vault for the edge cases. Make your #deployments boring again—and your #infosec auditors happy.

🚨 We’re going LIVE! 🚨
🎙️ #TalesFromTheField x Microsoft #Fabric PG
🗓️ Nov 11 | 🕙 10 AM ET
youtube.com/watch?v=qCRE...

Get the latest #MicrosoftFabric updates, feature walkthroughs & live Q&A with the PG!
🎥 Set reminder & Subscribe www.youtube.com/Talesfromthe...
#MSFabric #PowerBI #Analytics

Which programming language visual is fastest? Spoilers, one is CLEARLY faster and one is INCREDIBLY SLOW.

youtu.be/Mtagn2VvDYw

#powerbi #microsoft #microsoftfabric #msfabric #r #python #deneb

🚀 Missed the big #MicrosoftFabric PG session yesterday?
We’ve got you covered! Catch all the updates, insights, and demos straight from the experts.
🎥 Watch now 👉 www.youtube.com/watch?v=2k55...
💡 Subscribe to #TalesFromTheField for more #Data & #AI goodness!
#MSFabric #DataCommunity

Releases and CI/CD in Microsoft Fabric — with Variable Libraries That Keep Meaning Stable I keep saying the quiet part out loud: a modern warehouse ships meaning and trust, not just tables. If meaning changes invisibly, trust evaporates. Releases, Release Flow, and CI/CD in Microsoft Fabric are how you move quickly and keep confidence—by making change observable, reversible, and governed. Fabric’s Variable Library and a deliberate, database‑level metadata library are the glue that make this work day to day.

#MSFabric is still developing better #CICD and #Release tools, but there are already strong capabilities ready to be leveraged. This is a quick guide to developing a strong CICD and Release pipeline in you MS Fabric projects.

Bronze Is Live Now: what Mirroring + Shortcuts really change about cost, archives, and getting to Silver For years, “Bronze” quietly became a parking lot for periodic snapshots: copy a slice from the source every hour/day, write new files, repeat. It worked, but it was noisy and expensive—lots of hot storage, lots of ingest compute, and a tendency to let “temporary” landing data turn into de‑facto history. Fabric upends that with two primitives that encourage Zero Unmanaged…

In #MSFabric, we've been doing things the way we always have because it was supported, but with the latest developments in mirroring and shortcuts, #DataArchitects have new levers to use to reduce the costs of a data architecture. #DataEngineers can now use Bronze as a live layer, while archiving…

Materialized Lake Views (MLVs) in Microsoft Fabric A Materialized Lake View (MLV) is a table in your Fabric lakehouse that’s defined by a SQL query and kept up‑to‑date by the service. You write one CREATE MATERIALIZED LAKE VIEW … AS SELECT … statement; Fabric figures out dependencies, materializes the result into your lakehouse, and refreshes it on a schedule. Today, MLVs are in preview, SQL‑first (Spark SQL), and designed to make Medallion layers (Bronze → Silver → Gold) declarative instead of hand‑assembled pipelines.

In #MSFabric, one of my favorite new technologies are #MaterializedLakeViews. MLVs are currently in preview, but you can already see the potential to completely change the way #DataEngineers and #DataArchitects interact with and build multi-layer data architectures. The idea of #ZeroUnmanagedCopies…

🚀 This week on #TalesFromTheField!

Learn how to extend a #MicrosoftFabric Data Agent in your app using the #Python #SDK—we’ve got you covered!

Watch here: youtube.com/watch?v=YJu9...

Stay updated & subscribe: youtube.com/Talesfromthe...

#MSFabric #DataCommunity #Analytics #AI #LearnWithUs

The Microsoft Fabric Delta Change Data Feed (CDF) In Microsoft Fabric you’re sitting on top of Delta Lake tables in OneLake. If you flip on Delta Change Data Feed (CDF) for those tables, Delta will record row‑level inserts, deletes, and updates (including pre‑/post‑images for updates) and let you read just the changes between versions. That makes incremental processing for SCDs (Type 1/2) and Data Vault satellites dramatically simpler and cheaper because you aren’t rescanning entire tables—just consuming the “diff.” Fabric’s Lakehouse fully supports this because it’s natively Delta; Mirrored databases land in OneLake as Delta too, but (as of September 2025) Microsoft hasn’t documented a supported way to 

Today, for #FabricFriday, I'm taking a deep dive into one of the most promising features in the #MSFabric Lakehouse. That's the Delta Change Data Feed. Right now, #DataEngineers can only pull data from traditional delta files written in traditional ways, but one can see a future where mirrored…

A New Paradigm For Data Teams: The Changing Role of the Data Visualization Engineer When teams build warehouses the old way—source → bronze → silver → gold → semantic—visualization and semantic specialists are invited in at the end. Their job looks reactive: wire up a few visuals, name some measures, make it load fast enough. They inherit whatever the pipeline produced, then try to make meaning out of it. The failure mode is predictable: pixel‑perfect charts sitting on semantic quicksand, with definitions that shift underfoot and performance that depends on structures no one designed for the questions at hand.

In a previous post, I talked about a revelation I had with regard to the way we could architect #DataProducts in a more efficient way in #MSFabric. The more I thought about this, the more I thought that this change would have (and is currently having) a profound effect on the way we structure our…

FabCon Feature: Fabric Real‑Time Intelligence Real‑Time Intelligence (RTI) is the part of Fabric that treats events and logs as first‑class citizens: you connect live streams, shape them, persist them, query them with KQL or SQL, visualize them, and trigger actions—all without leaving the SaaS surface. Concretely, RTI centers on Eventstream (ingest/transform/route), Eventhouse (KQL databases), Real‑Time Dashboards / Map, and Activator (detect patterns and act). That tight loop—capture → analyze → visualize/act—now covers everything from IoT telemetry to operational logs and clickstream analytics.

#MSFabric #RealTimeIntelligence is another place where the announcements at #FabConEurope came in at a surprising pace. In this post, I do a deep dive into the entire subsystem, and call out what's new. This is another valuable #DataEngineering tool, and a big part of the #DP700.

A New Paradigm For Data Teams: The real bottleneck isn’t data, it’s definition Most data teams still run a tidy assembly line: ingest sources into bronze, standardize into silver, curate into gold, and only then wire up a semantic model for BI. That sounds rigorous—but it puts the business contract (grain, conformed dimensions, measure logic, security scope, and SLOs) at the very end. By the time the organization finally argues about what “AUM” or a compliant “time‑weighted return” …

A conversation last week with @ErinSanders got me thinking about how some of the #DataEngineering challenges we face come from the process that we use to develop #DataProducts. #MSFabric allows us to literally #BeginWithTheEndInMind and develop from the goal we are trying to reach, rather than…

FabCon Feature: Purview On edudatasci.net, I keep data mesh grounded in four behaviors: domains own data; data as a product; a small self‑serve platform; and federated governance (policies expressed as code and applied consistently). I also use foundational vs derived data products as a practical way to think about scope and ownership, and I recommend publishing products in Purview’s Unified Catalog so ownership, access and SLOs are discoverable to the org, not just the team that built them.

I was surprised by how much got released at #FabConEurope for #MSPurview and #MSFabric. In this post, I take you through what I think are the biggest announcements from a #DataMesh perspective and what they'll bring to your organization.

🚨 In less than 1 day we’re going LIVE! 🚨
🎙️ #TalesFromTheField x Microsoft #Fabric PG
📅 Sept 23 | 🕙 10 AM ET
@bradleyschacht.com @joshluedeman.com @dbabulldog.bsky.social @neerajny.bsky.social @sqlballs.com

youtube.com/TalesFromThe...
#MicrosoftFabric #PowerBI #Analytics #LiveEvent #MSFabric

What's New in MSSQL Extension for VS Code v1.36 Explore what’s new in the MSSQL Extension for VS Code v1.36, including Public Preview of Fabric Connectivity, SQL Database in Fabric Provisioning, and GitHub Copilot Slash Commands.

MSSQL Extension for VS Code: Fabric Integration and GitHub Copilot Slash Commands (Public Preview)

buff.ly/QfmPi5H

#sqlserver #vscode #msfabric #githubcopilot #mssql #database

What's new in SQL Server 2025 Streamline your entire data workflow, from real-time change capture to querying across cloud and on-prem databases, without complex migrations or code change...

What's new in SQL Server 2025 | Microsoft Mechanics with Bob Ward & Jeremy Chapman.

buff.ly/szHRImr

#sqlserver #database #data #sqlserver2025 #ai #json #msfabric

Don’t forget to tag #powerbi, #msfabric azuresql etc on your posts, otherwise they don’t show up
On feeds that are specific to those tags.