Do You Really Need a Semantic Layer? It Depends, But Probably Yes

A friend recently tagged me in a LinkedIn post that declared semantic layers a waste of time. It was meant to be controversial, and I have no doubt it succeeded based on the comment threads. While the post made a few fair points, it also gave me the nudge I needed to finally write something I’ve been meaning to for a while. Semantic modelling is a topic I care about deeply. Especially in Power BI, where the semantic layer isn’t an additional feature, it should be the foundation.

The post included an architecture diagram that placed the semantic layer as an external layer feeding into tools like Power BI and Looker. That’s a valid approach in some architectures, particularly when trying to enable headless BI or consistency across tools. Personally, I lean toward a Power BI-centric view, where the semantic model lives inside Power BI itself. When designed well, that model becomes the universal interface for everyone from dashboard creators to AI agents. Power BI also works well in a headless BI architecture. Its semantic layer can be exposed and consumed by other tools and services beyond the Power BI UI when XMLA endpoints, REST APIs, and the new Semantic Link Python library are used effectively.

Image thoughtfully produced on Canva© by Acendant Analytics

The key thing is this. Not every organisation needs a full-scale, centralised semantic model loaded with KPIs, definitions, business glossaries and lineage tracking. If you’re a small team working on a well-defined project, with limited complexity and no need to democratise analytics, then yes, materialised views and some documentation might be enough. This is an example where the overhead of a fully abstracted semantic layer may not be worth the payoff.

But the moment your organisation starts scaling, the cracks begin to show. These cracks might look like metrics drifting, definitions that diverge, or you discover teams have started building their own logic in isolated workbooks. Suddenly no one is quite sure what “churned customer” means, and the dashboards don’t match.

This is where the semantic layer starts to earn its keep. It acts as a contract between the data and its consumers. It defines not just what a measure is, but how the measure should behave. It gives AI tools context and business users clarity. Thankfully, it gives platform owners a fighting chance at managing technical debt too.

I’ve written previously about my experience building an enterprise BI platform across AWS and Power BI. I’ll link the full article at the end, but one of the biggest lessons I learned was that clarity and alignment do not emerge by accident. They have to be designed into the system, and the semantic layer is where that design lives.

That doesn’t mean it needs to be rigid or overly bureaucratic. But it does need to be deliberate. In Power BI, the semantic model is a living thing. It evolves alongside the business, so when it’s governed well, it doesn’t slow you down. It becomes the system of record that makes trusted self-service possible.

The rise of AI is making this even more important. LLMs don’t reason from scratch, they reason from structure. A clean semantic model gives them the business context they need to generate meaningful insights rather than fluent nonsense. It doesn’t matter how powerful your AI assistant is if it doesn’t know what a customer is, or how your revenue is calculated.

Of course, semantic models come with trade-offs. They require effort. They need maintenance. They demand agreement across stakeholders who don’t always agree. They will never be perfect. Still, they provide a foundation for scalable insight, reusable logic, and cross-team trust.

If you’re a small team working on tactical reports, you might not need one. If you’re building for scale, sharing definitions across departments, enabling AI, and trying to reduce the number of internal Slack threads that start with “Why does this dashboard look different to mine?” then a semantic layer might just be the best investment you can make.

Unfortunately, I’ve learned this the hard way, but you don’t have to. You can read about the rest of my lessons from building BI platforms here.