What’s in today’s newsletter:

AWS acquires DuckDB to boost embedded analytics capabilities🦆

Snowflake ends service account passwords, shifts to key authentication 🔐

Persistent tries rival LMDB in blockchain storage efficiency ⚡

Also, check out the weekly Deep Dive - The Semantic Layer

DEEP DIVE

The Semantic Layer

I should not be sharing this missive.

Earlier this week I sat through a demo of Power BI, and in particular a discussion on the Semantic Layer. Keep in mind, and I am dating myself, the only thing I know about reports is Crystal Reports, circa 2002.

I sat through the demo patiently, but I still left the call thinking “Is the Semantic Layer just a fancy ERD diagram representation?”.

I set out to do a little research into the subject. It got my mind off of the the Level 3 database engine/poor query design work on both SQL Server and vanilla Postgres I was doing this week.

Snowflake, Fabric, Databricks, Looker, dbt, Cube, AtScale and Palantir all talk about semantics. They are not talking about the same architecture.

For years, the semantic layer was mostly a business-intelligence concept: put a governed business abstraction between raw database structures and the people building reports. Today the term has expanded far beyond that. A Power BI semantic model, a Snowflake Semantic View, a Databricks metric view, dbt MetricFlow, a Cube semantic server and a Palantir ontology can all be described as "semantic," yet they solve materially different problems.

That is the most important point to keep in mind. Do not ask only whether a platform has a semantic layer. Ask what kind of meaning it models, where that meaning is authoritative, who can consume it, and which runtime actually executes it.

The result is one of the more consequential architecture shifts happening across the modern data stack. Semantic authority is moving out of individual dashboards and into reusable, governed infrastructure. But vendors are taking very different routes to get there.

At the simplest level, a semantic layer translates physical data structures into business concepts. A table may expose fct_ord.ln_amt, dim_cust.seg_cd and fct_ord.dt_key; the business wants Net Revenue, Customer Segment and Recognition Month.

But renaming columns is the easy part.

A serious semantic layer needs to know that Net Revenue is gross recognized revenue less discounts and refunds; that cancelled orders are excluded; that the correct time role is recognized_date; that the base grain is an order line; that region is reached through a particular customer or territory relationship; that the metric is additive across certain dimensions; and that some users may not be allowed to see every region.

In other words, the semantic layer is not merely friendly metadata. It is an executable contract for business meaning.

There is also a distinction that vendors increasingly blur: analytical semantics versus entity semantics. Analytical semantics answer questions such as, How should this number be calculated? They are about measures, dimensions, aggregation, grain, time and relationship behavior. Entity or ontology semantics answer, What business things exist, how are they related, and what can be done with them? Those are related problems, but they are not interchangeable.

Figure 1. Analytical semantics and entity/ontology semantics are different layers of business meaning.

The current market makes more sense when viewed as an evolution rather than a sudden invention.

The 1990s were dominated by OLAP cubes: dimensions, measures, hierarchies, drill-down and aggregation. In the 2000s, enterprise BI platforms such as BusinessObjects, Cognos and Oracle formalized logical business layers above physical databases. Microsoft Analysis Services carried the cube model forward and eventually into the tabular architecture that underpins modern Power BI semantic models.

The 2010s added two important shifts. First, self-service BI made semantic models more accessible to analysts. Second, platforms such as Looker made the model itself a software artifact: business logic could be defined in code, versioned and used to generate SQL.

Then came the headless metrics movement. dbt MetricFlow, Cube and AtScale pushed the idea that semantic definitions should not belong to one visualization tool. A metric could be modeled once and served to multiple consumers.

The newest move is downward into the data platform itself. Snowflake Semantic Views and Databricks metric views make semantics first-class warehouse or catalog objects. At the same time, Microsoft, Databricks and Palantir are expanding beyond analytical metrics into entity and ontology models.

That is why "semantic layer" now describes several architectures that once would have been separate product categories.

Figure 2. Evolution of enterprise semantic architecture.

Power BI remains one of the clearest examples of a mature executable analytical semantic model. The model owns tables, relationships, DAX measures, hierarchies, calculation behavior, formatting and row-level security, while the Analysis Services engine evaluates that logic. Direct Lake brings that engine closer to OneLake without changing the basic architectural principle: analytical semantics live in the model and are executed by a specialized semantic runtime.

Fabric now adds a second semantic construct: Ontology. That is important because Microsoft itself is effectively separating two kinds of meaning. The Power BI semantic model is the analytical authority; Fabric Ontology is intended to model reusable business entities and cross-domain context.

The architecture question is therefore not whether Fabric has a semantic layer. It has more than one semantic mechanism. The question is which object owns which meaning and how duplication is prevented.

Snowflake takes a different route. A Semantic View is a schema-level object that can define logical tables, relationships, row-level facts, dimensions, metrics and derived metrics. Rather than sending the user to an external BI engine, Snowflake can use the semantic definition to generate SQL against Snowflake tables.

Architecturally, that matters. The semantic model sits inside the same platform boundary as the data, privileges, tags and catalog metadata. Snowflake is effectively saying that analytical business meaning can become native database metadata and query infrastructure.

The benefit is locality: fewer moving parts, consistent platform governance and the opportunity to optimize semantic queries directly against the warehouse. The tradeoff is equally clear: the model is Snowflake-specific.

Figure 3. Snowflake Semantic View: semantic definitions drive SQL against physical Snowflake tables.

Databricks is converging from the lakehouse side. Unity Catalog metric views define reusable measures, grouping fields, joins, filters and related behavior as securable catalog objects. They are directly queryable through SQL and can participate in materialization and query-rewrite strategies.

That makes the metric view feel less like a BI artifact and more like governed data-platform infrastructure. Security and lineage can be tied to Unity Catalog, while the metric contract remains reusable.

Databricks is also developing a broader ontology/context layer through Genie, but the architectural distinction is similar to Fabric: deterministic analytical metrics should not be confused with a wider representation of business entities and contextual relationships.

Google still has one of the strongest code-defined semantic approaches in Looker. LookML models dimensions, measures, joins, relationships and Explores, and Looker generates SQL against the underlying database. The semantic definition is highly reusable and fits naturally into Git-based development.

BigQuery itself is gaining more native semantic capability, particularly through measures and graph-oriented constructs. But the important distinction today is that BigQuery-native semantics are still not a full replacement for the breadth of a mature LookML model.

Headless semantic layers make a different architectural bet: the semantic runtime should be independent of the presentation layer and, ideally, independent of a single warehouse.

dbt MetricFlow treats entities, dimensions and metrics as a semantic graph and resolves the joins required to answer a metric query. Cube adds a broad serving surface through SQL, REST, GraphQL and other interfaces, along with pre-aggregations and caching. AtScale brings a more traditional multidimensional semantic-server approach, including hierarchies, non-additive measures, BI protocol compatibility and automatic aggregate management.

Their common strength is consumer neutrality. Their common cost is that the semantic layer becomes another production system that must be secured, operated, monitored and made highly available.

Palantir is the clearest reminder that not everything called semantics is a metrics layer. Foundry Ontology models object types, properties, links and actions. It is closer to an operational digital representation of the enterprise than to a conventional BI semantic model.

A metric layer answers, What is Net Revenue? An operational ontology can answer, What is this customer or asset, how is it related to other objects, and which governed action can be performed on it?

Both are semantic. They are solving different problems.

For enterprise architects, the most important design decision is not the brand name. It is the location of semantic authority.

If one data platform clearly dominates the estate, a platform-native semantic architecture can be attractive. Snowflake Semantic Views and Databricks metric views fit naturally here. The advantages are fewer moving parts, native security, metadata locality and optimization close to the execution engine. The cost is tighter platform coupling.

Figure 4. Platform-native semantic reference architecture.

A headless semantic architecture makes more sense when the estate is deliberately heterogeneous: multiple warehouses, multiple BI tools, embedded applications or a strong requirement to avoid tying business meaning to one execution platform. dbt, Cube and AtScale are variations of this pattern.

The architectural advantage is one semantic contract serving many consumers. The disadvantage is that the contract now has its own runtime, identity model, APIs, caches and lifecycle to operate.

Figure 5. Headless semantic reference architecture.

Neither model is universally better. Platform-native semantics optimize governance locality. Headless semantics optimize consumer neutrality.

That is a much more useful comparison than a generic vendor feature checklist.

The industry is becoming more open at the query interface and much less open at the model-definition layer.

Consumers can increasingly reach governed semantics through SQL, JDBC, REST, GraphQL, XMLA and other APIs. But the authoring artifacts remain proprietary. A Power BI model expressed through TMDL/DAX is not a Snowflake Semantic View. A Semantic View is not a LookML model. LookML is not MetricFlow YAML. A Palantir ontology is not a Fabric ontology.

This creates a subtle risk. The biggest problem is not simply vendor lock-in; it is semantic duplication.

Imagine the same Finance metric implemented independently in dbt, a Snowflake Semantic View, Power BI, Tableau, an AI prompt and the business glossary. They may all start with the same definition. Over time they will drift.

A sustainable architecture needs to label every downstream semantic artifact as one of three things: authoritative, generated from the authority, or referential to the authority. "Manually synchronized" is not a long-term architecture.

The business definition itself should be governable independently of the syntax used by any one runtime. That means assigning owners, defining grain and time behavior, documenting relationship cardinality, specifying security assumptions, versioning changes and testing results.

I do not think the enterprise end state is one enormous universal BI model.

A more realistic target is a semantic control plane. The enterprise centrally governs canonical entities, certified metrics, relationships and cardinality, glossary terms, policy metadata, lineage, trust and validation. Those definitions can then be projected into the runtimes that are best suited to execute them: Power BI, Snowflake, Databricks, Looker or a headless layer.

The control plane does not necessarily execute every query. Its job is to establish meaning, ownership, compatibility and validation.

That reconciles two trends that otherwise appear contradictory:

Centralize meaning. Decentralize execution.

Figure 6. Enterprise semantic control plane: centralize meaning, decentralize execution.

This is also the strongest hedge available today against semantic lock-in. There is no broadly adopted interchange language that can move sophisticated analytical semantics - grain, cardinality, time behavior, calculation context, security and hierarchies - between the major runtimes without loss.

The semantic layer is becoming a foundational part of enterprise data architecture again, but it no longer describes one technology.

Power BI represents the mature executable BI model. Snowflake and Databricks are moving semantics into the warehouse and catalog. Looker remains a strong software-defined model. dbt, Cube and AtScale separate semantic logic from consuming tools. Palantir shows how far the idea can extend into operational ontology. Fabric is increasingly trying to connect analytical semantics with broader business entities and context.

The practical lesson is to stop treating the semantic layer as the place where dashboards get friendly field names.

Treat it as the governed, executable contract between enterprise data and the people, applications and analytical systems that are allowed to reason about that data.

Once that becomes the design principle, the vendor question becomes much easier: choose the runtime that best fits your enterprise gravity, but make sure the meaning is governed as an enterprise asset.

Gladstone Benjamin

Looking to reach CTOs, CIOs, and enterprise Data Engineers and Data Architects?

Limited sponsorship slots available each month.

👉 Sponsor Cloud Database Insider