---
title: "Semantic layer"
description: "A semantic layer is a layer between raw data and end users that defines business metrics, dimensions, and relationships once, so that different tools and teams query consistent, agreed-upon definitions instead of re-deriving them independently."
canonical: "https://motherduck.com/glossary/semantic-layer/"
related:
  - title: "Rethinking the Semantic Layer: AI Query Discovery vs. Manual Data Modeling"
    url: "https://motherduck.com/blog/who-needs-a-semantic-layer-anyway/"
  - title: "DuckLake | MotherDuck Docs"
    url: "https://motherduck.com/docs/concepts/ducklake/"
  - title: "Why Semantic Layers Matter — and How to Build One with DuckDB"
    url: "https://motherduck.com/blog/semantic-layer-duckdb-tutorial/"
---

# Semantic layer

> A semantic layer is a layer between raw data and end users that defines business metrics, dimensions, and relationships once, so that different tools and teams query consistent, agreed-upon definitions instead of re-deriving them independently.

## Overview

A semantic layer sits between the underlying data (tables in a warehouse or query engine) and the people and tools that consume it (BI dashboards, spreadsheets, ad hoc SQL, AI assistants). It defines metrics like "revenue" or "active users" and dimensions like "region" or "plan tier" in one place, along with how they relate to underlying tables, so that every consumer gets the same answer to "what is our revenue this month?" regardless of which tool they used to ask.

Without a semantic layer, the same metric often gets redefined slightly differently in every dashboard and every analyst's query — one dashboard excludes refunds, another doesn't, a third uses a different date field for "month." These small inconsistencies compound into a lack of trust in reported numbers.

<glossary-callout guide="ai-analytics-eval-field-guide" />

## What it typically defines

- **Metrics**: named, reusable calculations (e.g. `revenue = SUM(order_amount) WHERE status != 'refunded'`)
- **Dimensions**: attributes to slice and filter by (region, customer segment, product category)
- **Relationships**: how tables join to each other (which keys, which join type)
- **Governance**: descriptions, ownership, and access rules for each metric

## Where it lives

Semantic layers have historically been built into BI tools themselves (like LookML in Looker), but a newer generation of tools — including the dbt Semantic Layer and standalone products like Cube — define metrics independently of any single BI tool, so the same metric definition can be queried from multiple front ends: a dashboard, a notebook, a spreadsheet plugin, or a chat interface.

## Relationship to the underlying warehouse

A semantic layer doesn't replace transformation work — it sits on top of already-modeled tables (often the output of dbt models) and adds a metrics vocabulary. Under the hood, most semantic layers translate a metric request ("monthly revenue by region") into a generated SQL query against the warehouse or query engine, meaning the semantic layer is only as good as the modeled tables it queries.

## Why it matters

As more tools and, increasingly, AI agents query data directly, a semantic layer becomes the mechanism that keeps metric definitions consistent across all of them. Instead of every tool or LLM independently guessing how to compute "revenue" from raw tables, they can reference a single governed definition.