Understanding Microsoft Fabric Costs and Billing

Understanding the cost implications of implementing Microsoft Fabric is crucial for organizations transitioning to this unified analytics platform. This guide explores the fundamentals of Fabric's billing model, helping you make informed decisions about resource allocation and cost management. Microsoft Fabric costs is a difficult topic, apparently, let's make it a bit more understandable!

We will dive deep into the billing mechanism of Microsoft Fabric, unveil Capacity Units and Capacity Unit seconds.

We will look at the implications of the different Fabric Workloads on costs, and learn all about cost optimisation.

After this session you will have a thorough understanding of Fabric cost topics (Capacities, CUs, bursting, smoothing, throttling, cost optimisation, reservations, etc).

Your first Microsoft Fabric Lakehouse implementation

In this session, Bas, a seasoned data engineer with over a decade of expertise in SQL Server, Azure SQL, and now Fabric, shares his transition journey and insights from building data warehouses with SQL to building them with lakehouses in Microsoft Fabric.

In this session you will learn enough about Fabric and lakehouse concepts to start building your own solutions right away.

The session starts out with a few theoretical concepts to give guidelines, and is then filled with practical examples.
We will go through everything necessary for your first project. From setting up the Fabric Capacity to Workspaces management, environments and importing your own custom Python code.

We end with a practical case study where we implement a Fabric Lakehouse solution for a small B2B services company. During this part you will see examples of the Data Factory orchestration pipelines, the folder and file structure of the data lake, and the PySpark notebooks you need to transform your raw data into insightful information.

Analysing 4 billion rows of data using Power BI DirectLake and Fabric

Data volumes are going up and up. For most businesses, analysing more data at a faster pace becomes increasingly important to stay ahead.

In this session, I will demonstrate the use of Microsoft Fabric Lakehouses with a massive dataset containing 4 billion rows of data.
We will be looking at the performance implications of analysing such a huge dataset and showcasing Power BI's DirectLake capabilities to handle big data without copying.

After this session you will be able to:
1. Understand DirectLake vs Import & DirectQuery
2. Set up a Power BI DirectLake connection in Microsoft Fabric
3. Run analyses in real-time on datasets in the billions of rows, without breaking a sweat

First public delivery of this presentation, target audience: technical, data engineer, data analyst, preferred duration: 20-30 min

Don't Repeat Yourself, how custom Python modules in Microsoft Fabric give you back hours every day

Warning! This session may contain very DRY content!

Dont Repeat Yourself, or DRY, is a concept in software engineering that governs the way software is written by stating that you should never repeat yourself.

As a data engineer working with Microsoft Fabric, when you start building a data lakehouse you will be writing a lot of code to connect to source systems, copy and transform data, and orchestrate your ELT process.

Fabric allows you to write custom Python modules that can be called from within your notebooks, in order to streamline these processes.

Never again you'll have to write the same function twice again!

In this very practical session we will dive deep into:
1. Creating a very simple Python module using Visual Studio Code
2. Publishing our Python module to Microsoft Fabric
3. Calling functions in Python from Fabric notebooks

After this session you will go home never having to repeat yourself again, because you will be writing reusable Python modules for all your data engineering needs.

Aimed at the experienced data engineer, 45-60 minute duration, hands-on

Delta Table Optimisation - Improving Queries using Delta Partitioning and Liquid Clustering

Data volumes are skyrocketing, and with every new project, the pressure is on for data engineers to deliver performant queries over larger and larger datasets. In this session, we will deep dive into how Delta Lake’s partitioning and Liquid Clustering capabilities can transform query performance in Microsoft Fabric. We’ll be putting these optimisations to the test against a massive dataset to demonstrate real-world impacts on speed and efficiency.

We’ll explore the details of Delta partitioning to ensure your data is stored in the most optimal way, reducing query overhead and slashing runtimes. Then we’ll crank it up with Liquid Clustering, an advanced feature that automatically reorganises your data for faster queries. Finally, we’ll show you how to integrate these Delta optimisations into your Microsoft Fabric Lakehouse, so you can power your dashboards, reports, or machine learning pipelines with near real-time insights and without the dreaded performance bottlenecks.

By the end of this session, you will:
1. Understand when, why, and how Delta partitioning improves query performance.
2. Enable Liquid Clustering in Delta Lake to keep your data lean, mean, and query-ready.
3. Integrate partitioned and clustered Delta tables seamlessly with Microsoft Fabric for next-level analytics.

Brace yourself: This session may contain dangerously optimised partition strategies and an overdose of high-speed query demos! If you’re a data engineer looking for hands-on techniques to crush query latencies and boost productivity in Microsoft Fabric, then this is your must-attend deep dive. Get ready to leave your old, slow queries in the dust.

Dashboard are Dead, Talk to your Data!

I have spent the better part of my career designing, refining, and maintaining dashboards in Power BI to help my clients answer business questions. Until now.

In this session, we will break free from predefined visuals and fixed dashboards. It is time to talk to your data!

Over the past years, everybody has been exposed to AI LLMs such as ChatGPT, Claude, and Gemini.
What if I told you that you could chat with your data, just like you can chat with your AI?

With Fabric Data Agents, you can! You get a chat interface that understands the context of your data. You can ask questions in natural language (no need to learn SQL or DAX!) and get answers, fast.

In this session we will start by explaining some of the basics behind the Fabric Data Agents.
Then we'll jump into the prerequisites in order to start using the Data Agents.

After all the boring stuff is done I will take you into a live demo of setting up the Agent, tuning it to get accurate responses, and will show how we can chat with our own data to generate insights and drive decision making.

You'll walk away from this session understanding the following:
- Why this shift from dashboards to chatting matters for you and your organisation
- How Fabric Data Agents actually work "under the hood"
- How to build, configure, and use your first Fabric Data Agent

If you are involved in building modern data platforms, please consider Data Agents as an amazing tool to help users find insights faster!

Bronze, Silver, Gold: An Opinionated Guide to Medallion Architecture in Fabric

The medallion architecture has become the go-to pattern for organizing data in a lakehouse, but ask five people how to implement it, and you'll get seven different answers. Where does the business logic go? What belongs in silver? Should bronze even have Delta tables? If you've ever felt confused by contradictory advice on how to layer your data platform, this session is for you.

In this session, I'll walk you through how I implement the medallion architecture in Microsoft Fabric and more importantly, why. This is not a "it depends" kind of talk. I have strong opinions on what each layer should and should not do, shaped by years of building production data platforms. I'll share those opinions openly, explain the reasoning behind them, and show you what this looks like in practice inside a Fabric lakehouse.

We'll start at the bronze layer, where raw data from APIs, databases, and files lands in the Files section of a lakehouse before being structured into Delta tables. Then we'll move to the silver layer — and this is where my approach breaks from the crowd. No business logic. No transformations. No aggregations. Silver is a faithful, versioned, schema-managed mirror of your source systems, enriched only with lineage and system fields to support time travel and schema evolution. Finally, we'll arrive at the gold layer, where PySpark notebooks (or stored procedures) transform silver data into dimensional models following the Kimball methodology: ready to power Power BI semantic models, AI data agents, and beyond.

Whether you're a Power BI professional stepping into data engineering, a data engineer exploring Fabric for the first time, or someone migrating from another platform, you'll walk away with a clear, practical, and opinionated blueprint for structuring your data lakehouse. A basic understanding of data warehousing concepts and a general awareness of what Microsoft Fabric is will help you get the most out of this session.

After attending, you will be able to: explain the purpose and responsibilities of each medallion layer; design a bronze layer that separates raw file ingestion from Delta table structuring; implement a silver layer focused on source fidelity, schema evolution, and time travel — without business logic; build a gold layer using notebooks and stored procedures to deliver Kimball-style dimensional models; and make deliberate architectural choices about where logic belongs in your data platform.

The World's Worst Dashboard - A Gamified BI Experience With Fabric Apps

Visual BI has looked roughly the same since 2015. Bar charts, slicers, a page of KPI cards, maybe a tooltip page if you were feeling generous. Fabric Apps changed the options. With the Rayfin SDK you can deploy a real TypeScript web application into your Fabric workspace, running on Entra SSO, reading from the exact same Power BI semantic model your reports already use. Coding agents write most of that application for you.

So I built a Game Boy Color style game on top of a real Power BI semantic model. You walk around a tile world with the arrow keys and talk to NPCs. Sergeant Hall guards the gate and tells you when the books open and close. Pip sits by the fountain and knows which borough takes the most rides. Every conversation fires a validated DAX query at the semantic model and returns the answer in a typewriter dialogue box, which means the game updates when the nightly ETL run finishes. Total build time was about an hour of prompting, plus two rounds of fixing the things that broke.

In this session I build one live. We start from a written spec, generate look and feel with sprites and tiles as text arrays, wire the NPC dialogue menus to DAX queries against a real model, and deploy the whole thing to a workspace. Along the way I show the parts that went wrong the first time: text that renders unreadably at a 320x240 buffer, frame rate stutter from an over-ambitious render loop, and DAX that returns the right number to the wrong character. I also show the side-scrolling platformer (Mario, anybody?) version, because one genre was never going to be enough.

Then the honest part. Nobody is going to close their month end by walking a pixel avatar over to the finance NPC. What this unlocks is a category of data interface that Power BI reports cannot cover: onboarding experiences, interactive explainers for a board that will never open a report, client gifts that get talked about for a year, and internal tools where the write-back and the analytics live in the same governed workspace.

Aimed at Power BI and Fabric developers who are comfortable with semantic models and DAX and want to see how far Fabric Apps goes. You do not need to write TypeScript. You do need to be willing to let an agent write code you have not read line by line, and to be honest about when that is acceptable.

Level: 300. It assumes semantic models, DAX, and workspace permissions as background, and it covers a preview workload most attendees have not touched.

Target audience: Power BI developers, Fabric developers, BI consultants, and analytics leads who own semantic models and are wondering what Fabric Apps is actually for. Being a 90s kid helps but is not mandatory ;-)

Prerequisites: Working knowledge of Power BI semantic models and basic DAX. Familiarity with VS Code helps. No TypeScript, no game development experience.

Learning objectives:
- Explain what Fabric Apps and the Rayfin SDK are, how an app authenticates with Entra SSO, and how it queries a semantic model.
- Write a build spec that a coding agent can execute end to end, including the gotchas that show up between local host and a deployed workspace.
- Judge when a custom Fabric App is a better answer than a Power BI report, and when it is an expensive gimmick.

Your Dashboard Has No Stall Warning

The horn goes off in the cockpit and you have about two seconds. Looking at the airspeed indicator will not save you. It reads fine. It has read fine the whole time. The number on the panel that everyone watches is not the number that is about to kill you, and the only thing standing between you and the ground is a warning that fires on something else entirely, plus a response you have drilled so many times it happens before you have finished being surprised.

Now open the report you built last month. Fourteen visuals, six conditional formatting rules, three cards that have been red since March. Somewhere on that page is your airspeed indicator, the number every stakeholder asks about, the one that correlates with survival right up until it doesn't. Somewhere else, or nowhere at all, is the thing that actually ends the business. Nothing on the page tells anyone which is which, and nothing on it is allowed to interrupt.

I am a student pilot, and this is the part of flight school that would not leave me alone. In this session we work out why the instrument you watch is the wrong one, and what that means for the dashboards we ship. We take a real business case and argue about which metric is the real killer, because it is almost never the one on the title card. We build the warning around it: what it fires on, who owns it, and what the one trained response is. Then we deal with the other thirteen visuals, which get demoted rather than deleted.

Flying and BI dashboards have more in common than you might think. After attending this session, you will be able to:
1. Separate a proxy metric from the condition it actually stands for, and explain why the proxy reads healthy in exactly the situation that matters most.
2. Identify the one metric on a report whose movement demands an immediate response, and defend that choice against the metric your stakeholders currently ask about.
3. Build an alert with a named owner and a single written first action, and demote the remaining visuals to positions that support that response.