Why moving your semantic layer to a separate data platform might not be the obvious choice it seems.
Disclaimer: The opinions expressed in this post are my own and do not represent the views of my employer.
The Debate in 30 Seconds
The analytics industry is in a heated argument about where your business metrics should live:
- Camp A (BI-Tool-Centric): Define your semantic model in your BI tool. It’s where your users already are.
- Camp B (Data-Platform-Centric): Define your semantic layer in the data platform. Let every downstream tool consume it.
Camp B has been gaining momentum across the industry. This post walks through seven dimensions to help you critically evaluate both approaches before making a strategic decision.
A Note on Terminology
These two terms are often used interchangeably, but they mean different things:
- Semantic model — A concrete implementation: tables, relationships, measures, hierarchies, and business logic bundled into a queryable model. In Power BI, this is the semantic model (formerly “dataset”). It’s where your KPIs, time intelligence, and row-level security actually live.
- Semantic layer — The broader architectural concept: an abstraction that maps business terms to underlying data so consumers don’t need to know table structures or write raw SQL. In Power BI, most often the semantic layer sits on top of one or more semantic models, but it can also incorporate other data sources — lakehouses, warehouses, APIs, or real-time streams.
Throughout this post, “semantic model” refers to the BI tool’s implementation, while “semantic layer” refers to the platform-level abstraction.
1. Maturity & Capability
| BI-Tool-Centric | Data-Platform-Centric | |
|---|---|---|
| Calculation Power | Mature expression languages with decades of investment. Time intelligence, many-to-many, calculation groups, dynamic formatting. | Early-stage. Most platform semantic layers support basic aggregations and simple expressions. |
| Modeling Richness | Star schemas, role-playing dimensions, display folders, synonyms, perspectives, hierarchies. | Flat or lightly relational. Still catching up on enterprise modeling patterns. |
| Verdict | ✅ Mature, proven at scale | ⚠️ Promising but nascent |
Key question to ask: “Can your semantic layer handle the 20 most complex measures in our current BI model? Show me.”
2. Performance
| BI-Tool-Centric | Data-Platform-Centric | |
|---|---|---|
| Query Speed | In-memory engines, aggregation tables, query folding — built for sub-second interactive analysis. | Depends on warehouse engine. Adds network hops. Optimized for large-scale transforms, not slice-and-dice exploration. |
| User Experience | Instant filter, drill, cross-highlight. Users expect this. | Latency varies. Risk of degraded interactivity that frustrates business users. |
| Verdict | ✅ Purpose-built for interactivity | ⚠️ Acceptable for dashboards, risky for exploration |
Key question: “When a business user applies three slicer filters on a 50M row dataset through your semantic layer — how fast does it respond in the slowest realistic scenarios, not just on average?”
3. The “Last Mile” Problem
Even if you externalize metric definitions, the BI tool still needs:
- Conditional formatting rules
- Visual-level filters and default aggregations
- Display folders and field organization
- Synonyms and linguistic metadata (for Q&A / NLP)
- Report-level measures and layout-specific logic
The platform semantic layer doesn’t eliminate BI-tool-specific work. It just splits your logic across two places.
You still maintain the BI tool. Now you also maintain the platform layer. That’s not simplification — that’s added complexity.
4. Governance
| BI-Tool-Centric | Data-Platform-Centric | |
|---|---|---|
| Single Source of Truth | Already established in many orgs. Endorsed datasets, data lineage, deployment pipelines. | Promises centralization but adds a new governance surface. Now you govern the platform layer AND the BI layer. |
| Row-Level Security | Mature, integrated, tested. | Must be re-implemented or passed through — another seam where things break. |
| Business Ownership | Business analysts can see, test, and validate metrics in the tool they use daily. | Metrics live in a platform business users can’t access. Ownership shifts to engineering. |
| Verdict | ✅ Governance where users are | ⚠️ Governance where engineers are |
Key question: “When a business user disputes a number, can they trace the metric definition themselves — or do they need to file a ticket with the data platform team?”
5. The AI Agent Angle
This is the emerging frontier. AI agents need semantic context to reason about data. The question is: which semantic layer feeds them?
| BI-Tool-Centric | Data-Platform-Centric | |
|---|---|---|
| Richness for AI | BI models already contain relationships, hierarchies, descriptions, business logic — exactly what an agent needs to generate accurate answers. | Metric definitions exist, but often lack the relational richness and business context an agent needs. |
| Proximity to Users | Agents that sit on top of the BI model serve the same users who already trust that model. | Agents on the platform layer may produce answers that don’t match what users see in their BI reports — eroding trust. |
| Maintenance | One model feeds both reports and agents. | Two models: one for agents (platform), one for visuals (BI). Drift risk is real. |
Key question: “If my AI agent and my BI report give different answers for the same KPI, which one is wrong — and whose job is it to fix it?”
6. The Lock-In Reality
A common argument against BI-tool semantic models is lock-in. Let’s be honest about what’s really happening:
| Claim | Reality |
|---|---|
| “Your BI tool is locking you in!” | Moving your semantic layer to any data platform is… also lock-in. You’re choosing which dependency to accept. |
| “We’re open and interoperable!” | Every platform’s semantic layer has proprietary syntax, proprietary APIs, and proprietary tooling. “Open” is a spectrum, not a binary. |
| “Define once, consume everywhere!” | In practice, every consuming tool interprets the layer differently, supports different subsets, and requires tool-specific workarounds. |
| “This is customer-driven!” | The push for platform-centric semantic layers shifts the center of gravity — and revenue — to the data platform. Follow the incentives. |
Key question: “If I adopt your semantic layer and want to switch data platforms in 3 years, how portable are my metric definitions?”
7. Who Actually Has This Problem?
The platform-centric approach assumes you need one semantic layer serving many BI tools. But ask yourself:
- How many BI tools does your organization actually use at scale?
- Of those, how much genuine metric overlap exists between them?
- Is the overlap large enough to justify an entirely new architectural layer?
For most enterprises, the honest answer is: we’ve standardized on one BI tool, and the multi-tool problem is theoretical. The platform semantic layer is an elegant solution to a problem you probably don’t have.
The Decision Framework
To make this actionable, here’s a decision tree that walks you through the key questions. Follow the green path — if you keep answering “Yes,” you’ll end up where most enterprises belong.
✅ Stay BI-Tool-Centric When:
- You’ve standardized on one primary BI tool
- You have deep investment in existing semantic models
- Business users own and validate metric definitions
- Interactive query performance is critical
- Your AI/agent strategy can sit on top of the BI model
- You don’t have a genuine multi-tool consumption problem
⚠️ Consider Data-Platform-Centric When:
- You genuinely operate 3+ BI tools with significant metric overlap
- Your primary consumers are programmatic (APIs, agents, apps) rather than visual
- You’re early in your analytics journey with no entrenched BI semantic model
- You’re willing to accept the added complexity and governance overhead
Bottom Line
The data-platform semantic layer movement solves elegantly for a scenario that affects a minority of organizations, while introducing architectural complexity, governance fragmentation, and performance trade-offs for everyone else.
Before you rearchitect your semantic layer because you were told it’s “strategic,” ask the hard questions above. The answer for most enterprises today is: your BI tool’s semantic model is already the foundation of your semantic layer — and that’s not a weakness. It’s a huge strength.
For a deeper technical perspective on why stacking semantic models on top of each other doesn’t work, I highly recommend Chris Webb’s post Power BI And Support For Third Party Semantic Models. He explains the architectural reasons why — from SQL generation assumptions to metric aggregation conflicts — putting one semantic model on top of another creates fundamental problems that aren’t specific to any single tool.
Don’t let industry narratives make your architecture decisions. Let your users, your governance model, and your actual consumption patterns guide you.