Fix the Semantic Model First: Lessons on Power BI, Snowflake and AI

I just watched Snowflake's Power BI webinar and it mirrors my client work: AI and BI only succeed when the semantic model is right. Daisy-chaining is a trap.

I just finished watching a Snowflake webinar called Supercharge Your Power BI Architecture with Snowflake Interactive Analytics. It's presented by Josh Crittenden, a Principal Solution Engineer at Snowflake who describes himself as "a recovering Power BI architect". I liked him already.

I tuned in to catch up on what's new in Snowflake for Power BI teams, and there's plenty: a new type of compute built for dashboards and AI, plus some big hints about where Snowflake's semantic layer is heading. But about halfway through, I realised it was also describing, almost word for word, the conversations I'm having with clients right now.

Those conversations usually start with "we want to use AI with our data". Almost every time, they end up at the semantic model.

So here's my view, and the reason for this post: businesses will only unlock AI on their data once they sort out their semantic model. And if you're on Power BI (whatever you think about its long-term future, and I'll get to that), the ideas in this webinar will help you deliver BI that is faster, cheaper and easier to trust today.

First, what is a semantic model?

A semantic model is the layer between your raw data and the people (and now the AI agents) asking questions of it. It holds the business meaning: what "revenue" actually means, how customers relate to orders, which filters apply, and who is allowed to see what.

Different tools call it different things. In Power BI it's the semantic model (it used to be called a dataset). In Snowflake it's a semantic view. In dbt it's the semantic layer. The names change, but the job is the same: define the business once, so every report and every AI answer uses the same definitions.

I've written more about why this matters for generative AI in Semantic Models for AI: The Missing Foundation for Reliable Enterprise GenAI.

The big shift: thousands of small questions, from people and agents

Josh opens with a point that's easy to skip past.

Data warehouses were built for a small number of big, complex queries over huge datasets, like overnight data loads and heavy transformations. But that's not how data gets used anymore. Today it's thousands of small, fast queries arriving at the same time: from dashboards, embedded analytics, apps calling APIs and, increasingly, AI agents. In his words, it's "the same type of queries ran over and over and over again by thousands of users and agents."

That line stuck with me. An AI agent answering "how did sales go in Chicago last August?" is asking exactly the same question as someone clicking a slicer on a Power BI report. Same data, same business logic, same need for a fast and correct answer.

If your model is messy, your dashboard is slow and your AI is wrong. Different symptoms, same root cause.

What's new in Snowflake, in plain terms

Snowflake's answer to this shift is the interactive warehouse, a type of compute designed to return answers in under a second while lots of people use it at once. The highlights:

• Speed and cost. Snowflake's own benchmarks show around 9x more queries per second at 200 concurrent users, and roughly 40% fewer credits per hour than a standard (Gen 1) warehouse in US regions.
• No extra copy of your data. As of a few weeks before the webinar, interactive warehouses can query your existing tables directly.
• Your security comes with it. Row-level security and data masking set up in Snowflake still apply when Power BI queries the data live. In the demo, masked customer details stayed masked inside the Power BI report.
• Some trade-offs. They're designed to stay switched on (a one-hour minimum charge and a 24-hour default before they pause), and any query taking longer than five seconds is cancelled and re-run on a backup "fallback" warehouse. Power BI doesn't notice, but it tells you what this engine is built for: lots of small, focused questions, not big ones.

The demo was impressive. Josh queried a 7 billion row sales table from Power BI using the smallest interactive warehouse Snowflake offers, with a Premium Per User licence, across two different clouds. Most clicks came back in under a second.

But the part I want you to take away isn't the speed. It's what he said next.

"It depends", and what it depends on is your model

When asked whether this works for Power BI, Josh gave the honest consultant's answer: it depends. Snowflake can only control so much.

Power BI in DirectQuery mode (where Power BI asks the database live, rather than storing a copy of the data) is, in his words, "notorious for generating, to be blunt, ugly SQL queries." Every visual on a report page has a DAX query behind it, and each DAX query can turn into one or more SQL queries. Put 25 visuals on a page and you've fired off dozens of queries before anyone has read a single number.

In other words, the fastest engine in the world won't save a badly designed model. His best practices are, I'd argue, simply good semantic modelling:

1. Use a star schema, and build it upstream. Shape your data into fact tables (things that happen, like sales) and dimension tables (things that describe them, like customers, products and dates) in the data warehouse, not inside Power BI. Power Query should be "a thin pointer" to clean, curated tables. As Josh put it, "the most performant models that I've ever encountered when working with customers are the simplest data models."
2. Don't bring in big, wide tables just because the warehouse can handle them. Snowflake can cope with them. Power BI semantic models don't like them.
3. Add aggregations. These are smaller summary tables that Power BI uses automatically when a visual doesn't need the full detail. In the demo, trend charts over 7 billion rows were answered from much smaller summary tables instead (one had 87 million rows), and some queries came back in around 100 milliseconds. The summary tables were built as Snowflake dynamic tables that refresh themselves incrementally, so keeping them up to date is cheap.
4. Open report pages with filters already set. Focused questions are fast. A page that opens with no filters is asking for everything.
5. Use fewer visuals per page, and set visual interactions on purpose. Power BI is a multi-page tool for a reason. Every cross-filter click triggers more queries.
6. Keep relationships simple. One-to-many relationships from dimensions to facts, and avoid bi-directional relationships.

Notice that none of these are Snowflake features. They're design decisions. That's exactly my point.

The Q&A: where it got really interesting

The questions at the end were the best part of the webinar, because they were the same questions I hear from clients. A few of them were about something I'd call the daisy-chain problem.

"Can Power BI use a Snowflake semantic view?"

Josh's answer: not natively today. And he wouldn't recommend the workaround (a native query) because "that's essentially just daisy-chaining two different semantic layers together."

Here's why this matters. Snowflake's semantic views were originally built to power Cortex Analyst, which lets people and AI agents chat with their data. Now customers want Power BI to read those same semantic views. But Power BI is already its own semantic layer. Stack one on top of the other and you end up with:

• two places where "revenue" is defined
• two places to maintain and test
• two places to secure
• two places that will slowly drift apart.

This is often where the real considerations sit. The question usually isn't "which tool is better?" It's "where should our business definitions live?" Get that wrong and you can end up rebuilding the same metrics, relationships and security rules across two different platforms, then paying to keep them in sync for years.

Snowflake's planned answer is an XMLA endpoint, in private preview at the time of the webinar. It would let Power BI see a Snowflake semantic view as if it were an Analysis Services tabular model, the same technology that sits underneath Power BI semantic models. That means one semantic layer, used by both your BI and your AI.

For me, this is the most important idea in the whole webinar: the goal isn't to have a semantic model in every tool. It's to have one trusted definition of your business that every tool, and every agent, can use.

"How efficient are DAX measures in DirectQuery?"

This answer had two more daisy chains in it.

The first is fact tables. "Do not daisy chain your fact tables together," Josh said. Instead, connect them through shared dimensions (data people call these conformed dimensions), like Date, Customer and Product. That's what lets you compare sales with returns, or budget with actuals, cleanly.

The second is measures. Time intelligence like year-to-date, prior year and trailing 12 months works fine in DirectQuery. The trouble starts when a poorly designed model forces complicated DAX, with "DAX measures that are calling other DAX measures that are calling other DAX" and so on.

The lesson I take from this: complicated measures are usually a symptom of a problem in the model. Fix the model and the DAX gets simpler.

I see a third version of this inside Power BI itself. Teams build new reports on top of existing published semantic models, then build more models on top of those. Microsoft even has a name for it: chaining. Sometimes it's the right call, but every link adds another place for definitions to drift and performance to suffer.

The other questions worth your time

• "Does this help with Import mode?" Not really. Import mode copies the data into Power BI's memory, and then "the valve back to Snowflake is shut off until the next scheduled refresh." Interactive warehouses help when Power BI is asking live questions.
• "DirectQuery with aggregations, or a hybrid model?" "If real-time data is imperative, DirectQuery is the best option, full stop." Otherwise, it depends on your data volumes and how people actually use the reports. His example was factory sensor data: transform it in Snowflake, serve it from an interactive warehouse, and show it in Power BI with automatic page refresh on the factory floor. My take is to choose the storage mode based on how fresh the business needs the data to be, not on habit.
• "How do we stop one workload slowing down another?" Give separate workloads their own compute, including a dedicated warehouse for each large semantic model. A bonus is that you can see what each solution costs to run, which is a governance win, not just a performance one.
• "Do we still need a Fabric capacity?" Josh was refreshingly honest here: yes, most enterprises will still need a Microsoft Fabric capacity. This isn't Snowflake or Microsoft. It's about putting each workload where it runs best.

So, does Power BI have a future?

This is genuinely up for debate, so here's my take: Power BI will be around for a while yet, but the way we build and use it is about to change completely. I see three shifts.

1. Less building by hand. A lot of BI work today is manual: writing DAX, setting up relationships, tuning aggregations and laying out report pages. That's moving to AI doing the building through MCP (Model Context Protocol) servers and connectors. Microsoft already has a Power BI Modeling MCP server in preview that lets an AI agent create tables, measures, relationships and security roles in a semantic model. Even in this webinar, Josh used Snowflake's AI coding assistant to help design his aggregation tables. As he put it, "it's late 2026 now", and nobody needs to bang their head against the wall setting these things up.

2. In the longer term, it all becomes conversational. Instead of opening a dashboard and clicking through slicers, people will ask questions in plain language and an AI agent will answer from the semantic model. Snowflake's semantic views were built for exactly this, and both Microsoft and Snowflake now offer MCP servers that let AI agents query semantic models directly.

3. AI shouldn't be the reason you're locked into a platform. Right now, part of the pull towards Fabric is Copilot, which needs a paid Fabric or Premium capacity. But open standards like MCP mean any AI agent can connect to any well-built semantic model, wherever it lives. That puts the choice back with the business, not the vendor.

Which brings me back to my main point. If AI is going to build the models and answer the questions, then the semantic model becomes the most important thing you own. An AI agent building on a messy model just builds a mess faster. An AI agent answering from a daisy-chained model can give you two different answers to the same question.

A clean star schema, clear metric definitions, shared dimensions and security set at the source all carry over, whichever way the tools go.

So if you're on Power BI today, the smartest move isn't to rip it out or to double down. It's to treat your semantic model as the asset, not the report, and to keep it open enough for whatever comes next.

How I'm applying this with clients

This lines up closely with how I deliver projects and solutions. Here's what it looks like in practice:

1. Start with the questions, not the tool. I work with leaders and teams to agree on the decisions that matter, the 10–20 metrics behind them, and who's asking: people, apps or AI agents. This is the use-case discovery and prioritisation step, and it shapes everything after it.
2. Give every definition one home. We decide where the semantic layer lives, whether that's Power BI and Fabric, Snowflake or dbt, and make it the single source of truth, so nothing has to be rebuilt on a second platform. No daisy chains.
3. Push the heavy lifting upstream. Star schemas, conformed dimensions and aggregation tables get built in the data platform, so Power BI stays thin and fast.
4. Design for how the model will be used. That means default filters, fewer visuals, aggregations where they help, and a storage mode chosen for the freshness the business actually needs.
5. Build governance in at the source. Row-level security, data masking, separate compute and clear cost visibility, set once and carried through to both dashboards and AI.
6. Make it ready for AI. Connect the semantic model to AI agents through MCP and connectors, so AI can help build and maintain it, and people can start asking it questions in plain language.
7. Leave the team able to run it. I work embedded alongside internal teams and pair delivery with hands-on enablement, so the knowledge stays when the project ends.

It's the same approach behind the Power BI and Microsoft Fabric reporting overhaul in my case studies, and it's what gets a business ready for AI that people can actually trust.

Final thought

On the surface, this webinar is about speed. But the real lesson is about clarity. A fast engine rewards a good model and exposes a bad one, and the same is true for AI.

Fix the semantic model first. The dashboards get faster, the AI gets more accurate, and you stop paying to build and maintain the same logic on two different platforms.

If you're working through this right now, whether it's Power BI performance, deciding where your semantic layer should live or getting your data ready for AI, let's talk.

Quotes are from the webinar recording. Performance and cost figures are Snowflake's own benchmarks, as presented in the session.