The Semantic Layer Renaissance

Semantic layers had their first wave in the 1990s, in tools like Business Objects and Cognos. By 2020 the term sounded vaguely embarrassing – legacy BI vocabulary. By 2026 it’s back at the centre of the data stack. The semantic layer is what makes AI on data actually work.

The dbt angle

dbt’s semantic layer (originally Transform’s MetricFlow, acquired into dbt Labs in 2023) is the analytics-engineer’s entry point. Define your entities, dimensions, and measures in YAML alongside the dbt models. Define metrics as combinations of those measures with filter and grouping logic. dbt compiles the queries on demand. Tools that speak dbt’s semantic layer API can ask for “revenue by region last quarter” and get a correct SQL query without writing the SQL.

What makes this work is that the metric definitions are version-controlled, code-reviewed, and tested. The metric isn’t in someone’s head or in a Power BI workbook; it’s in the dbt project.

The warehouse angle

Snowflake and Databricks both shipped native semantic layers in 2024-2025. Snowflake’s Semantic Views and Cortex Analyst, Databricks’ Genie. The semantic layer lives in the warehouse itself, with native query compilation and access control.

This is useful for warehouse-native shops. It’s also a lock-in vector: a Snowflake Semantic View doesn’t run on Databricks.

The OSI angle

The most interesting recent development is the Open Semantic Interchange specification, finalised in early 2026. OSI is a vendor-neutral standard for expressing semantic models. Snowflake-led, dbt Labs as founding member, Apache 2.0. The pitch: define once in OSI; export to Snowflake, dbt, Cube. Whether it achieves interoperability remains to be seen.

Why now

Three things converged. First, the SQL-everywhere problem. The 2010s strategy of teaching everyone SQL and skipping the semantic layer produced analysts who disagree on what the numbers mean. The semantic layer is the structural answer.

Second, the AI angle. LLMs need explicit semantics. Text-to-SQL works on a semantic layer; it doesn’t work on a raw warehouse.

Third, governance. Regulated industries need to point at “this is our definition of customer” and have it be authoritative.

The choice

• Define in dbt, compile anywhere. Portable, requires good dbt discipline.
• Define in the warehouse natively. Tightest integration, locks you in.
• Define in OSI. Best in theory, least mature.
• Define in a dedicated tool (Cube, AtScale). Most BI-tool-agnostic.

My current bias is to define in dbt. Portability is real; the semantic layer API has the broadest tool support. Treat the warehouse features as deployment targets.

The federated picture

In a large organisation, you have many semantic layers. The federated pattern: each domain owns its definitions; cross-domain platforms consume published metrics from each. dbt Mesh is the dbt-native version – publish metrics from one project; other projects consume them as imported packages.

The semantic layer is back. The work people had to do anyway is the same work that makes the AI layer work. The investment is no longer optional.

Next week – tool use is the new ETL.