5 years ago, a good BI developer could survive by knowing Power BI really well I don’t think that’s enough anymore….
Not because Power BI is becoming less important.
Because the BI ecosystem is becoming much bigger.
Today, a strong BI developer should understand what happens beyond the report:
🔹 Data Engineering
How data is ingested, transformed and stored.
🔹 Microsoft Fabric
Lakehouse, Warehouse, Pipelines, Notebooks, Dataflows and more.
🔹 Semantic Modeling
Not just creating relationships, but building a model that can actually answer business questions.
🔹 Data Governance
Who owns the data?
Can we trust it?
Where did it come from?
🔹 AI & Copilot
How do we make our data understandable and useful for AI?
🔹 Performance & Architecture
Why is a report slow?
Where should the transformation happen?
Import, Direct Lake or DirectQuery?
Power BI is still the tool but understanding the entire data journey is becoming the real skill.
Not because Power BI is becoming less important.
Because the BI ecosystem is becoming much bigger.
Today, a strong BI developer should understand what happens beyond the report:
🔹 Data Engineering
How data is ingested, transformed and stored.
🔹 Microsoft Fabric
Lakehouse, Warehouse, Pipelines, Notebooks, Dataflows and more.
🔹 Semantic Modeling
Not just creating relationships, but building a model that can actually answer business questions.
🔹 Data Governance
Who owns the data?
Can we trust it?
Where did it come from?
🔹 AI & Copilot
How do we make our data understandable and useful for AI?
🔹 Performance & Architecture
Why is a report slow?
Where should the transformation happen?
Import, Direct Lake or DirectQuery?
Power BI is still the tool but understanding the entire data journey is becoming the real skill.
Power BI is quietly becoming a developer platform.
Most Power BI updates are about another visual, another formatting option, or another small improvement. But the August 2026 release feels different.
Look at the direction:
PBIP → Git → VS Code → Semantic Models → OneLake → Fabric
That's not just a dashboarding workflow anymore.
It's starting to look a lot more like software development. Power BI is moving from:
“Build a report → Publish it”
towards:
“Develop → Version → Govern → Deploy → Scale”
Features like Theme Pane going GA, improvements around semantic model refresh, and continued investment in PBIP + developer tooling are small pieces of a much bigger shift.
The interesting question isn't: “What new features did Power BI get this month?”
It's: “What is Microsoft trying to turn Power BI into?” I think we're going to see the answer more clearly over the next few releases. Power BI isn't just becoming better at making dashboards. It's becoming better at building BI products.
Most Power BI updates are about another visual, another formatting option, or another small improvement. But the August 2026 release feels different.
Look at the direction:
PBIP → Git → VS Code → Semantic Models → OneLake → Fabric
That's not just a dashboarding workflow anymore.
It's starting to look a lot more like software development. Power BI is moving from:
“Build a report → Publish it”
towards:
“Develop → Version → Govern → Deploy → Scale”
Features like Theme Pane going GA, improvements around semantic model refresh, and continued investment in PBIP + developer tooling are small pieces of a much bigger shift.
The interesting question isn't: “What new features did Power BI get this month?”
It's: “What is Microsoft trying to turn Power BI into?” I think we're going to see the answer more clearly over the next few releases. Power BI isn't just becoming better at making dashboards. It's becoming better at building BI products.
🔥1
📊 How does the choice of Power BI storage mode affect report performance with Azure Databricks?
Liping Huang's new white paper, Modern Power BI Architecture Choices For Reporting On Azure Databricks, focuses exclusively on performance benchmarking. It compares four ways of serving the same Delta tables to a Power BI report:
🔹 Direct Lake on OneLake
🔹 Direct Lake on mirrored Unity Catalog tables—shortcuts with no data copy
🔹 DirectQuery on a Databricks SQL warehouse
🔹 Composite Model—DirectQuery with Import-mode aggregations
Explore the benchmark results to understand the performance characteristics of each architecture.
Liping Huang's new white paper, Modern Power BI Architecture Choices For Reporting On Azure Databricks, focuses exclusively on performance benchmarking. It compares four ways of serving the same Delta tables to a Power BI report:
🔹 Direct Lake on OneLake
🔹 Direct Lake on mirrored Unity Catalog tables—shortcuts with no data copy
🔹 DirectQuery on a Databricks SQL warehouse
🔹 Composite Model—DirectQuery with Import-mode aggregations
Explore the benchmark results to understand the performance characteristics of each architecture.
Interview tip💡
What if there is NO active relationship and NO inactive relationship between two tables in Power BI? 🤔
Which DAX function would you use to create a relationship-like behavior between the tables?
Most developers immediately think of:
USERELATIONSHIP()
But here's the catch...
❌ USERELATIONSHIP() cannot help if no relationship exists in the data model. It only activates an existing inactive relationship. If there is no relationship at all, there's nothing for USERELATIONSHIP() to activate.
✅ The correct answer is: TREATAS()
TREATAS() creates a virtual relationship by applying values from one table as filters on another table during measure evaluation.
Example Sales Amount = CALCULATE( SUM(Sales[Amount]), TREATAS( VALUES(Customer[CustomerID]), Sales[CustomerID] ) )
How It Works
🔹 Takes values from one table
🔹 Applies those values as filters to another table
🔹 Simulates a relationship without creating a physical model relationship
🔹 Useful when working with disconnected tables
What if there is NO active relationship and NO inactive relationship between two tables in Power BI? 🤔
Which DAX function would you use to create a relationship-like behavior between the tables?
Most developers immediately think of:
USERELATIONSHIP()
But here's the catch...
❌ USERELATIONSHIP() cannot help if no relationship exists in the data model. It only activates an existing inactive relationship. If there is no relationship at all, there's nothing for USERELATIONSHIP() to activate.
✅ The correct answer is: TREATAS()
TREATAS() creates a virtual relationship by applying values from one table as filters on another table during measure evaluation.
Example Sales Amount = CALCULATE( SUM(Sales[Amount]), TREATAS( VALUES(Customer[CustomerID]), Sales[CustomerID] ) )
How It Works
🔹 Takes values from one table
🔹 Applies those values as filters to another table
🔹 Simulates a relationship without creating a physical model relationship
🔹 Useful when working with disconnected tables
Microsoft just quietly changed what Fabric is.
And if you’re in data, you need to understand this shift🔺
At Build 2026, Microsoft announced that Fabric is going agentic.
It’s no longer just a data analytics platform. It’s becoming the backend for AI agents.
Let me break down what’s actually new
👇 Agent Skills for Power BI (now in preview) AI assistants can now:
▸ Create semantic models on their own
▸ Author PBIR and PBIP report files
▸ Manage reports end to end without manual intervention
“Power BI Modeling MCP Server” -
This one’s big for anyone who follows AI tooling.
- A skill can now call a Power BI Modeling MCP server to build a semantic model directly.
- That means AI agents aren’t just reading your data anymore. They’re modelling it.
Here’s the real shift nobody is saying out loud:
Then → Fabric was the platform where analysts built things for stakeholders.
Now → Fabric is the platform where agents build things for analysts.
Your job isn’t disappearing.
But the entry point for what you need to know just moved higher.
The analysts who understand semantic models, governed data, and how MCP servers work will be the ones directing these agents.
The ones who don’t will be waiting for someone else to explain the output.
And if you’re in data, you need to understand this shift🔺
At Build 2026, Microsoft announced that Fabric is going agentic.
It’s no longer just a data analytics platform. It’s becoming the backend for AI agents.
Let me break down what’s actually new
👇 Agent Skills for Power BI (now in preview) AI assistants can now:
▸ Create semantic models on their own
▸ Author PBIR and PBIP report files
▸ Manage reports end to end without manual intervention
“Power BI Modeling MCP Server” -
This one’s big for anyone who follows AI tooling.
- A skill can now call a Power BI Modeling MCP server to build a semantic model directly.
- That means AI agents aren’t just reading your data anymore. They’re modelling it.
Here’s the real shift nobody is saying out loud:
Then → Fabric was the platform where analysts built things for stakeholders.
Now → Fabric is the platform where agents build things for analysts.
Your job isn’t disappearing.
But the entry point for what you need to know just moved higher.
The analysts who understand semantic models, governed data, and how MCP servers work will be the ones directing these agents.
The ones who don’t will be waiting for someone else to explain the output.