What Is a Semantic Layer? Definition, Types, Tools and Examples

A semantic layer is the place where a company writes down what its data means. Instead of every analyst, dashboard and AI agent working out for themselves how to calculate revenue from an orders table, the calculation is defined once, given a name, and reused. Ask for net revenue by country in a BI tool, a spreadsheet or a chat window, and the semantic layer turns that request into the same SQL every time.

Why do semantic layers exist?

A warehouse table does not say what it means. A column called amount could be gross or net, with or without tax. So the logic gets written wherever it is needed, and soon finance and product report two different revenue numbers, each correct according to its own SQL. The fix, a shared business vocabulary, is old: Business Objects was granted a US patent for it in 1996 (Wikipedia). Two things brought it back: cloud warehouses let many tools query the same tables, and LLMs made plain-language questions possible, which only works if something tells the model what the columns mean.

How does a semantic layer work?

A semantic layer sits between the warehouse and everything that queries it. It usually holds definitions, not data: the tables stay where they are, and the layer generates SQL against them at query time, in four steps. Because that SQL comes from a stored definition, two people asking the same thing get the same query.

Key components of a semantic layer

Vendors use different names, but most semantic layers have the same parts, plus a query interface (SQL, an API or a BI connector) and the compiler that generates the SQL.

A semantic layer example: one metric, defined once

Here is a concrete example in the dbt Semantic Layer YAML spec (dbt v1.12 and later). A semantic model is one modelled table inside the layer: it declares the entities, dimensions and metrics that the table provides. The example has two. fct_orders holds one row per order and defines a net_revenue metric. dim_customers holds one row per customer and contributes the country dimension.

models:
  - name: fct_orders
    description: "One row per order."
    semantic_model:
      enabled: true
    agg_time_dimension: ordered_at
    columns:
      - name: order_id
        entity:
          type: primary
          name: order
      - name: customer_id
        entity:
          type: foreign
          name: customer
      - name: ordered_at
        granularity: day
        dimension:
          type: time
      - name: sales_channel
        dimension:
          type: categorical
    metrics:
      - name: net_revenue
        label: Net revenue
        description: "Completed orders, minus refunds."
        type: simple
        agg: sum
        expr: case when status = 'completed' then amount - refunded_amount else 0 end

  - name: dim_customers
    description: "One row per customer."
    semantic_model:
      enabled: true
    columns:
      - name: customer_id
        entity:
          type: primary
          name: customer
      - name: country
        dimension:
          type: categorical

Nothing in that file is a query. It says what an order is, how it relates to a customer, and how net revenue is calculated. A consumer then asks for the metric by name and chooses how to slice it:

dbt sl query --metrics net_revenue --group-by metric_time__month,customer__country

The layer works out that country lives on the customer table, finds the join through the shared customer entity, and compiles SQL of this shape (simplified for reading; the generated query is more verbose):

SELECT
  DATE_TRUNC('month', o.ordered_at) AS metric_time__month,
  c.country                         AS customer__country,
  SUM(
    CASE WHEN o.status = 'completed'
         THEN o.amount - o.refunded_amount
         ELSE 0 END
  )                                 AS net_revenue
FROM analytics.fct_orders AS o
LEFT JOIN analytics.dim_customers AS c
  ON o.customer_id = c.customer_id
GROUP BY 1, 2;

Ask for the same metric by week and sales channel and the join disappears, the grain changes, and the CASE expression stays identical. The rule that refunds are subtracted and cancelled orders are excluded lives in one line of the definition, not in forty dashboards. Change it there and every consumer picks it up.

Types of semantic layer

Semantic layers differ mainly in where the definitions live. That decides which tools can use them.

Two neighbouring terms cause confusion. A metrics layer is the part of a semantic layer that defines metrics; the terms are often used interchangeably. A semantic model is a single modelled unit inside a layer: dbt uses the term for one annotated table, and Microsoft uses it for the data model behind Power BI reports. In knowledge management, "semantic layer" can also mean a knowledge graph of taxonomies and ontologies; this guide covers the analytics meaning.

Benefits of a semantic layer

• One number per metric. Revenue in the board deck matches revenue in the product dashboard, because both call the same definition.
• Self-service without SQL. People pick a metric and a dimension. The join logic is no longer something each user has to get right.
• Changes happen once. When the definition of an active user changes, you edit one object instead of hunting through reports.
• Grounding for AI. An LLM that reads named, described metrics has far less to guess than one that reads raw column names.

Semantic layer tools compared

There is no single best semantic layer tool. The right one depends on where your definitions already live and who consumes them. Each row links to the vendor documentation it was checked against in October 2026.

The last column is the short answer. If your transformations are in dbt, start there. If the consumer is software, look at Cube. If one BI tool or data platform serves nearly everyone, its native layer is the least work.

If you need a finance metric in Tableau, Mitzu is the wrong tool; if you need a five-step funnel or a retention curve, a metrics layer is the wrong shape.

Open source semantic layer options

Two of the engines are open source. MetricFlow is distributed under the Apache 2.0 license, and Cube Core has an Apache 2.0 backend and an MIT-licensed client. AtScale has open-sourced its modelling language, SML, while its platform is a commercial product. There is also a shared format in progress: Apache Ossie (incubating), formerly the Open Semantic Interchange, defines a JSON and YAML specification for exchanging semantic models between tools, and dbt documents that MetricFlow works with it.

The semantic layer for AI: grounding LLMs and agents

An LLM pointed at a raw warehouse is a new analyst on day one with nobody to ask. It sees amount, status and cust_id, and it guesses. Snowflake measured this on its own evaluation set: single-prompt GPT-4o text-to-SQL reached 51% accuracy, while Cortex Analyst, which pairs an agentic system with a semantic model, reported more than 90% (Snowflake Engineering). That is a vendor benchmark, but every tool in the table above now grounds its AI the same way. Looker's Conversational Analytics is grounded in LookML, and Databricks adds synonyms to metric views so Genie can find the right measure.

A semantic layer gives an LLM or agent three things:

• Vocabulary. Named, described metrics and dimensions, so sales, revenue and turnover resolve to the same object.
• Safe paths. Declared joins and cardinalities, so the model does not invent a join that double counts.
• A narrower task. Choosing a metric and three dimensions from a catalogue is far easier than writing a correct 40-line query.

Two designs: the model writes SQL, or the model fills in a request

In the first design, the LLM still writes SQL with the semantic layer as context, and can still get the query wrong in ways that run. In the second, the LLM never writes SQL. It produces a structured request (metric, dimensions, filters) and the layer's compiler generates the query, so the same request always yields the same SQL. Metrics layers such as dbt and Cube support this through their APIs, and dbt and AtScale expose their layers to agents through an MCP server. Analytics agents vs text-to-SQL compares the two designs in depth.

The limit of a metrics-shaped semantic layer

Grounding fixes vocabulary, not method. A metrics-and-dimensions layer answers questions of the form aggregate X by Y. Much of product analytics has a different form: an ordered sequence of events per user, a time window between steps, a cohort tracked week by week. Some metrics layers cover the simplest case: dbt has a conversion metric for one base event followed by one conversion event within a window. A five-step funnel with per-step drop-off, a retention curve or a path analysis is usually not a first-class object in that shape, so it becomes a hand-built SQL model or SQL the LLM improvises. That is where errors hide: steps out of order, no conversion window, a user counted twice, and a plausible number at the end. Why an analytics agent needs a semantic layer walks through this with annotated funnel SQL.

Mitzu's semantic layer for product analytics

Mitzu is an agentic product analytics platform that runs on your data warehouse, and its semantic layer is shaped for that job. Instead of metrics and dimensions, it stores events and their properties, entities (users and groups) with their dimension properties, and sampled filter values from the warehouse, so a filter on country uses a value that exists in your data. Saved insights and cohorts join the vocabulary over time.

Nobody writes it by hand. The Configuration Agent scans the warehouse, recognises event and dimension tables (Segment, Snowplow, GA4, Firebase and custom schemas), maps the user ID, timestamp and event name columns, and asks about ambiguous ones. An analyst reviews the result in the app, and indexing keeps it in sync as the data changes.

Mitzu then applies the second design to behavioural analysis. The Analytics Agent does not write SQL. It assembles an analysis specification: for a funnel, the first event, the following steps, the conversion window and the breakdowns; for retention, the cohort event, the return event and the time granularity. A deterministic query engine, the same one behind the no-code funnel and retention builders, turns the specification into SQL. The method lives in the engine, so the model cannot get it wrong, and every answer shows its SQL for review (how the agent works).

The two kinds of layer are complementary: finance metrics in dbt or metric views for BI, a product analytics layer for behavioural questions, both on the same warehouse tables. The Mitzu semantic layer page shows the product side.

Semantic layer implementation challenges

The technology is the easier half. Projects usually stall for one of these reasons.

• Agreeing on definitions. Deciding what an active user is takes a negotiation between teams, and no tool settles it. Start with five metrics people already argue about, not five hundred.
• Authoring and upkeep. Hand-written models go stale when the schema changes, and a stale layer produces confident wrong answers.
• Coverage gaps. Whatever the layer cannot express, people compute outside it, and you have two sources of truth again.
• More than one layer. A BI tool, a warehouse and a metrics tool can each hold definitions. Decide which is the source; interchange formats such as Apache Ossie are still young.
• Performance and cost. Generated SQL runs on your warehouse, and wide joins over large fact tables get expensive. Several tools offer caching, pre-aggregation or materialisation for this.
• Thin metadata. A layer built for dashboards often has field names and little else. LLMs need descriptions, synonyms and real example values to choose the right field.

FAQ

What is a semantic layer?

A semantic layer is a governed set of definitions between the raw tables in a data warehouse and the people, BI tools and AI agents that query them. It maps columns and joins to business terms such as revenue, customer and active user, and compiles requests for those terms into SQL, so each metric is defined once and returns the same number everywhere.

What is the function of the semantic layer in Databricks?

In Databricks, the semantic layer role is played by Unity Catalog semantics, whose core implementation is the metric view. A metric view separates measure definitions from the dimensions used to group and filter them, so a metric such as revenue per customer is defined once and grouped by any available field at query time. Metric views are written in YAML, queried with MEASURE(), and used by SQL editors, notebooks, dashboards, Genie and alerts.

What is a semantic model example?

A semantic model example is an orders table described in business terms: order and customer as entities, order date and sales channel as dimensions, and net revenue as a metric defined as the sum of amount minus refunds for completed orders. A request for net revenue by month and country then compiles to SQL that joins orders to customers and groups by both. The full YAML and SQL are in the example above.

What are the best semantic layer tools?

There is no single best one. The main semantic layer tools are dbt Semantic Layer (MetricFlow), Cube, AtScale, Looker with LookML, Databricks Unity Catalog metric views and Snowflake semantic views. dbt fits teams that already model in dbt, Cube fits embedded analytics and data apps, AtScale fits enterprise BI on Excel and Power BI, and the platform-native options fit stacks built on one warehouse. For funnels and retention, Mitzu provides a semantic layer built for event data.