The Data Brief · Issue #3 · Semantic Layer Series
A decision framework for choosing the right semantic layer type — before you build the wrong one
The most expensive architectural mistake is not choosing the wrong tool. It is choosing the right tool for the wrong moment — and spending twelve months discovering the difference.
By now, most data leaders understand that they need a semantic layer. The harder question — the one this issue tackles directly — is which kind. Because "semantic layer" in 2026 is not a single thing. It is a family of architectural patterns, each with a fundamentally different trade-off profile.
The whiteboard version — logical, physical, hybrid, virtualisation, universal — is a useful teaching taxonomy. But in practice, the 2026 market has consolidated around three deployable patterns, each with a clear philosophical stance on where semantic logic should live.
Looker LookML, Power BI Tabular models, Tableau Semantics
Semantic logic lives inside your BI tool. Metrics, joins, and business rules are defined in the tool's proprietary language and consumed exclusively through that tool's interface. The trade-off is fundamental: depth of integration versus portability. LookML is powerful and mature — but it does not travel.
One BI tool accounts for 90%+ of analytics usage and you have no near-term plans to change that. Your team has deep expertise in the tool's semantic language.
Watch out for: the moment you introduce a second BI tool, an AI assistant, or an embedded analytics use case — at that point, BI-native semantics become a liability.
Snowflake Semantic Views (GA March 2026), Databricks Metric Views, dbt Semantic Layer (MetricFlow)
Semantic logic lives in your data platform, not your BI tool. Snowflake Semantic Views reached full general availability with standard SQL querying in March 2026. Databricks Metric Views extend Unity Catalog to cover metrics with the same governance controls already applied to tables.
The semantic layer landscape has shifted from a single-vendor story to a genuine architectural choice. Multi-warehouse teams lean toward dbt, Snowflake-native teams lean toward Semantic Views, and teams wanting both governance and native SQL are using the dbt_semantic_view package to get both.
You are committed to a single primary data platform and want the lowest-overhead path to governed metrics.
Watch out for: multi-cloud or multi-warehouse environments. If your data lives across more than one platform, a platform-native semantic layer will not span the gap.
Cube, AtScale, GoodData
Semantic logic lives in a dedicated, platform-independent layer that sits between your data sources and all consumers — BI tools, AI agents, notebooks, embedded applications, and APIs. Define a metric once. Every consumer gets the same answer, regardless of which tool they use to ask.
"The universal semantic layer has evolved beyond accelerating BI. It has become the control plane for enterprise AI."
You use multiple BI tools, multiple data platforms, or AI-powered analytics in production. You need metrics consistent across dashboards, notebooks, embedded apps, and AI agents simultaneously.
Watch out for: organisational readiness. Universal semantic layers require buy-in from multiple teams. Start with platform-native and migrate later if your organisation is not ready for that coordination overhead.
| Question | If yes → consider |
|---|---|
| Do 90%+ of your analytics queries flow through a single BI tool with no near-term plans to change? | BI-native — it already works, don't add complexity |
| Are you all-in on Snowflake, Databricks, or BigQuery, with dbt already in your stack? | Platform-native — lowest overhead, fastest time to value |
| Do you use multiple BI tools, or are AI agents consuming your metrics in production? | Universal — the only pattern that serves all consumers equally |
| Are you early-stage with limited data engineering capacity? | Platform-native first, universal later — sequence matters |
The most common mistake: choosing universal because it sounds most sophisticated, then spending six months on infrastructure before a single metric is defined. Pattern ambition should match organisational maturity. A well-governed platform-native semantic layer delivers more value than a half-implemented universal layer at the same company.
The most common evolution pattern is to start BI-native, then add a universal layer once a second BI tool or AI assistant is introduced. The emerging Open Semantic Interchange initiative — co-founded by dbt Labs, Snowflake, and Salesforce — aims to define metrics in vendor-neutral YAML consumed by every tool. Until that standard matures, the choice remains a practical one based on your current stack.
Next in the series
Design your semantic model: metrics, KPIs, and naming the whole organisation agrees on