What Is a Semantic Layer? Definition and Analytics Tools Support Compared

A semantic layer is the place where a company writes down, once, what its numbers mean. It says how "revenue" is calculated, which tables join to which, what "active customer" means, and who can see what. BI tools, spreadsheets, and AI agents then ask the semantic layer for "revenue by region" instead of writing their own SQL against raw tables.

This article gives a precise definition, shows what goes inside one, and compares how Looker, Power BI, Tableau, dbt, Cube, Snowflake, Databricks, and a few smaller tools support it. All capability claims come from each vendor's own documentation.

What is a semantic layer?

A semantic layer is a governed layer between your data warehouse and the tools that read from it. It holds metric definitions, dimensions, join paths, business names, and access rules, so that different tools get the same answer to the same question.

Cube describes it as an independent, governed layer between your data sources and the tools that consume data. AtScale lists the five things it standardizes: metrics, dimensions, relationships, business terminology, and access rules. dbt frames it as a central place to build and store metric logic so many endpoints can read consistent, governed data.

The idea is old. In 1991, Business Objects patented a "relational database access system using semantically dynamic objects", which became the "Universe". The first semantic layers were tied to one BI product such as MicroStrategy, Business Objects, or Cognos. Today the same idea exists in four places: inside the BI tool, inside the transformation tool, inside the warehouse, or as a standalone service that any tool can query.

A 2021 Forrester survey found that over 61% of organizations use four or more BI tools, and 25% use ten or more! With that many tools, each one defining "revenue" on its own produces different numbers in different dashboards.

What does a semantic layer contain?

A semantic layer contains logical tables, dimensions, facts, metrics, relationships, synonyms, descriptions, and access rules. Snowflake's semantic view spec is the clearest public list of these parts, so I use its vocabulary here.

Snowflake's spec separates facts, which are row-level values, from metrics, which aggregate facts. A derived metric can combine metrics from several tables, for example a profit margin built from total revenue and total cost.

Here is a minimal semantic view in Snowflake's YAML format, following the spec:

name: sales
tables:
- name: orders
base_table:
database: analytics
schema: marts
table: fct_orders
primary_key:
columns: [order_id]
dimensions:
- name: region
synonyms: ["market", "territory"]
expr: region
data_type: VARCHAR
facts:
- name: order_amount
expr: amount
data_type: NUMBER
metrics:
- name: revenue
description: "Sum of order amounts"
synonyms: ["sales", "total sales"]
expr: SUM(orders.order_amount)

The same spec also carries verified queries, which pair a natural-language question with the SQL that answers it, and a top-level staleness setting. Setting max_staleness turns on materialization, and the minimum allowed value is 120 seconds.

Other tools use different formats for the same parts. Looker uses LookML. Power BI uses TMDL, the Tabular Model Definition Language, plus DAX for measures. dbt uses MetricFlow YAML. GoodData uses MAQL, its Multi-Dimension Analytical Query Language. Databricks uses SQL DDL or a UI with YAML validation. The parts are the same; the file format changes.

Is a semantic layer a data warehouse, a dbt model, or an OLAP cube?

A semantic layer is a layer of meaning over stored data, so it is a different thing from the warehouse that stores the data, the dbt models that shape it, and the OLAP (Online Analytical Processing) cubes that once pre-computed it. Modern vendors ship all of them in one product, which blurs the lines.

Warehouse. A relational database stores and organizes data in structured tables without focusing on business meaning. A semantic model adds clear names, relationships, and predefined metrics on top. Snowflake and Databricks now ship semantic objects inside the warehouse, which raises the question of whether Snowflake is a semantic layer. The answer is that Snowflake is a warehouse that also has a semantic layer feature, called semantic views.

dbt models. dbt models are SQL transformations that produce tables. The dbt Semantic Layer defines metrics on top of existing models and handles the joins at query time. So the semantic layer is a separate layer that reads from your models, even when both are in the same repo.

OLAP cubes. In the 1990s, relational databases were too slow for complex analysis. The OLAP cube solved the performance problem through pre-aggregation: the system pre-calculated answers for combinations of dimensions before anyone asked. A semantic layer instead generates SQL at query time, and uses caching or materialization as an optimization rather than as the core design.

Where does a semantic layer fit in an ELT stack?

The semantic layer comes after ingestion and transformation, and before BI, spreadsheets, and AI. In an ELT stack (Extract, Load, Transform: load raw data first, then transform it inside the warehouse), the order is sources, ingestion, warehouse, transformations, semantic layer, consumers.

Ingestion is the first step. Erathos extracts data from a source such as PostgreSQL or HubSpot, stages it in a cloud bucket, and loads it into the warehouse with COPY or the destination's equivalent, then deletes the temporary files. Destinations include BigQuery and Databricks, both of which have their own semantic layer features downstream (Looker's LookML on BigQuery, Unity Catalog metric views on Databricks).

Transformations come next, usually in dbt, and produce the clean tables the semantic layer reads. Then the semantic layer defines metrics over those tables. Then BI tools, Excel, notebooks, and AI agents query the semantic layer. If you want the ELT background first, we wrote up ETL vs ELT and the key differences.

The semantic layer only works if the tables under it are complete and fresh. A metric like revenue is wrong if last night's orders never loaded. That is why pipeline observability on the ingestion step matters to the people who own the metric definitions, even though they rarely touch ingestion.

Why do AI and text-to-SQL tools benefit from a semantic layer?

AI text-to-SQL tools benefit from a semantic layer because a database schema alone does not say how the business calculates its metrics. Snowflake states that generic AI solutions struggle with text-to-SQL when given only a schema, because schemas lack business process definitions and metrics handling.

The semantic layer supplies exactly the missing pieces: metric formulas, join paths, synonyms ("sales" means revenue), descriptions, and verified example queries. Snowflake's Cortex Analyst is a REST API that uses semantic views to generate SQL. Databricks lets Genie agents query metric views the same way dashboards and notebooks do. Strategy Mosaic documents MCP access (Model Context Protocol, the standard AI agents use to call tools) next to its SQL, DAX, MDX, and REST interfaces.

None of the primary docs I read publish an accuracy number for text-to-SQL with and without a semantic layer, so I am not quoting one. The model can only be as correct as the definition it is given.

A semantic layer is also a different thing from a "context layer" or an "ontology", terms that show up in the same AI conversations. MotherDuck's summary of the difference is useful:

Which analytics tools support a semantic layer?

Most BI platforms, the main cloud warehouses, and dbt all support a semantic layer, but they put it in different places. The useful way to sort them is by where the definitions are stored and whether other tools can read them.

Two details from the table deserve a closer look.

Power BI treats third-party semantic layers narrowly: it supports only SAP BW, SAP HANA (as a multidimensional source), and AtScale as external semantic models. Layering a third-party semantic model between Power BI's own model and the database is generally unsupported, because combining two semantic layers can produce incorrect results.

Superset goes the other way. Its own layer is thin: virtual metrics are SQL aggregations and virtual calculated columns customize single columns. With the experimental SEMANTIC_LAYERS feature flag, Superset can connect to external layers such as dbt Semantic Layer or Cube as data sources.

How do Looker, Power BI, Tableau, dbt, Cube, Snowflake, and Databricks compare?

Here is the detailed comparison, built only from each vendor's documentation. Where a document did not cover a column, the cell says so rather than guessing.

The Databricks external BI pattern is the plainest example of a warehouse-native layer reaching an outside tool. Any BI tool that can pass SQL through runs this:

SELECT
`Order Month`,
MEASURE(`Total Revenue`),
MEASURE(`Order Count`)
FROM main.sales.orders_metric_view
GROUP BY ALL;

Every measure must go through the MEASURE() function and metric views do not support SELECT *. For tools that cannot pass custom SQL, Databricks documents a wrapper view that bakes the MEASURE() calls into a standard view, so the BI tool reads it like any table.

On the dbt side, here is the list of native integrations:

What are the tradeoffs and implementation pitfalls?

The main tradeoffs are lock-in to one tool's format, limits on how outside tools can query the layer, and the cost of keeping cache or materialization fresh. Each vendor documents its own version of these tradeoffs.

Format lock-in. LookML, TMDL, MetricFlow YAML, Snowflake YAML, and MAQL are all different languages for the same concepts. Moving a metric catalog from one to another is a rewrite. Databricks partially addresses this with Genie Code, which imports a Tableau or Power BI file and recreates the data model as a metric view.

Outbound query limits. Looker's Open SQL Interface is SELECT only, with no JOIN, window functions, or subqueries, and it needs a BigQuery-backed LookML project. Metabase metrics work only in its query builder. A "semantic layer" that only its own product can read is a metrics feature, and that is fine as long as you only have one BI tool.

Two layers stacked. Microsoft says layering a third-party semantic model under a Power BI semantic model is generally unsupported because the combination can give wrong numbers. If you adopt dbt or Cube as the central layer, plan for Power BI to read it through a native integration or an export, and keep Power BI's own model thin.

Freshness versus speed. Cube's pre-aggregations, Snowflake's materializations, Databricks's incremental materialization, and dbt's declarative caching all trade freshness for speed. Snowflake makes the trade explicit with a max_staleness value in seconds that you have to choose.

Row limits. Cube returns at most 10,000 rows by default and 50,000 at the maximum. A semantic layer is for aggregated answers; bulk extracts still go against the warehouse directly.

When should a team centralize a metric?

A metric belongs in the semantic layer when more than one tool or team reads it, or when a wrong value would change a decision. A one-off calculation in a single notebook can stay local.

The mechanisms the tools provide tell you what "centralized" should look like. Snowflake's spec has verified queries with a question, the SQL that answers it, who verified it, and when. dbt's layer defines a metric once on top of existing models, so a change to the definition reaches every integration that queries it. Metabase separates verified metrics from unverified ones on its paid plans.

So a centralized metric has a description, synonyms people use for it, an owner, at least one verified query, and a change history in Git or in the tool. Anything less is a saved calculation, and it will drift.

Recap

• A semantic layer holds metrics, dimensions, relationships, business names, and access rules between the warehouse and the tools that read it.
• It is a different layer from the warehouse, from dbt models, and from OLAP cubes, even when one vendor ships all of them.
• The layer can be inside the BI tool, inside the transformation tool, inside the warehouse, or run as a standalone service. The key question is whether other tools can query it without redefining the metric.
• AI text-to-SQL tools need the semantic layer because a schema alone does not carry metric definitions.
• The metric is only as good as the tables under it, so ingestion has to land complete and on time.

Erathos handles that ingestion step: connect a source, choose a destination like BigQuery or Databricks, and the data lands in the warehouse ready for dbt and the semantic layer on top. Try Erathos free for 14 days.