The dbt Semantic Layer is dbt Labs' attempt to add metric definitions to the most-used transformation tool in the data ecosystem. It lets you write metrics: and semantic_models: blocks in your existing dbt project, and then query those metrics from any BI tool, notebook, or AI agent through a SQL or GraphQL endpoint. The strategic logic is straightforward: dbt is already where your data models live, so dbt is the obvious place for your metric definitions to live too.

The execution has been bumpier. dbt Labs has shipped two distinct versions of the Semantic Layer, the second of which is built on MetricFlow, the engine the company acquired when it bought Transform / Supergrain in February 2023.

Origin Story

The first version of the dbt Semantic Layer shipped in dbt 1.3 in October 2022. It was a simple metrics: YAML block that let you declare metric definitions inside a dbt project. The execution was outsourced — partner BI tools (Mode, Hex, Lightdash, Thoughtspot, etc.) would read the metric definitions and compile their own SQL to evaluate them. There was no central query engine. This v1 was conceptually correct but technically limited: it could not handle complex multi-table joins, ratio metrics, or windowed calculations without a lot of dbt model gymnastics.

dbt Labs realized fairly quickly that the v1 design was insufficient. Rather than building a metric query engine from scratch, they did the obvious thing: acquired the company that had already built one. Transform, founded by ex-Airbnb data engineers, had built MetricFlow — an open-source semantic-layer query engine specifically designed to compile metric requests into optimized SQL. dbt Labs acquired Transform in February 2023, deprecated the v1 metrics format, and rebuilt the dbt Semantic Layer on MetricFlow.

The MetricFlow-based version (sometimes called "v2" or just "the dbt Semantic Layer") shipped in late 2023 and is the version dbt Labs sells today. It is dramatically more capable: it understands joins, supports cumulative and ratio metrics, handles slowly changing dimensions, and exposes a real query API.

What It Looks Like

A dbt Semantic Layer model has two parts: a semantic model (which describes a logical entity, its dimensions, and its measures) and a metric (which is a calculation on top of those measures).

semantic_models:
  - name: orders
    model: ref('fct_orders')
    entities:
      - name: order_id
        type: primary
      - name: customer
        type: foreign
        expr: customer_id
    dimensions:
      - name: order_date
        type: time
        type_params:
          time_granularity: day
      - name: status
        type: categorical
    measures:
      - name: order_total
        agg: sum
        expr: amount
      - name: refund_total
        agg: sum
        expr: refund_amount

metrics:
  - name: revenue
    type: derived
    type_params:
      expr: order_total - refund_total
      metrics:
        - name: order_total
        - name: refund_total

Once these are defined, a BI tool or AI agent can ask the Semantic Layer "give me revenue by status by month" and MetricFlow compiles it into SQL against the warehouse, joining the right tables, filtering correctly, and returning a result.

dbt exposes the Semantic Layer through a JDBC endpoint (so any SQL tool can connect) and a GraphQL API (for programmatic clients). Tableau, Hex, Mode, Power BI, Lightdash, Thoughtspot, and a growing list of AI tools have first-class integrations.

The Opinionated Take

The dbt Semantic Layer has the best distribution story in the semantic layer category, full stop. Roughly every modern data team running dbt is one YAML file away from having metric definitions in production. No new tool to install. No new vendor relationship. No new repository. The friction is as low as it can be.

That distribution advantage is the single biggest threat to Cube, AtScale, and the standalone semantic layer vendors. Cube has a better product in some ways, but Cube has to convince customers to add a new service to their stack. dbt has to convince customers to add ten lines to a YAML file they already maintain.

The catches:

1. The Semantic Layer is dbt Cloud only. MetricFlow itself is open source (BSL license), and you can run it locally for development, but the production query endpoint — the part where BI tools and AI agents actually call it — requires a dbt Cloud subscription. For dbt Core users, this is a problem. It is also dbt Labs' main monetization lever for the feature.

2. It is still maturing. The MetricFlow-based version is good but newer than Cube and dramatically newer than LookML. Some advanced metric patterns (multi-fact joins, complex slowly changing dimensions, fanout-prevention) are still rough. dbt Labs is investing aggressively to close these gaps.

3. dbt Labs' overall strategy is shifting. With the Fivetran/dbt merger announcement in late 2025, dbt is becoming part of a larger data movement-and-transformation platform. Whether the Semantic Layer remains a first-class product or gets folded into a broader "Fivetran metrics" offering is uncertain. The current direction is clearly toward more investment, but enterprise buyers are nervous about consolidations.

The honest prediction: the dbt Semantic Layer becomes the default semantic layer for the modern data stack within a few years, not because it is the best technically but because the distribution is unbeatable. Cube and AtScale will continue to win specific niches (embedded analytics, enterprise/legacy), but the broad middle market will default to dbt because the dbt project is already there.

Where It Fits in the Stack

The dbt Semantic Layer sits inside the dbt project, which means it sits inside your warehouse:

• Below: dbt models, which sit on Snowflake, Databricks, BigQuery, Redshift, Postgres
• Above: Tableau, Hex, Mode, Lightdash, Thoughtspot, Power BI, Looker, AI agents
• Sideways: dbt Cloud's IDE, dbt Explorer (lineage UI), dbt Mesh

A typical dbt Semantic Layer user is an analytics engineer who already maintains a dbt project and wants to centralize metric definitions without adopting a new tool.