What is a semantic layer?
What a semantic layer does, the parts every one shares, the five places one can live, and how dbt MetricFlow, Snowflake semantic views, Databricks metric views, Cube and a layer defined in code compare today.
Definition
What is a semantic layer?
A semantic layer is a shared definition of your business metrics, dimensions and joins that sits between raw tables and everything that queries them. A dashboard, an API or an AI agent asks for “revenue by country”, and the layer decides which column, aggregate, joins and filters that means, then writes the SQL.
Without one, each dashboard and query defines revenue again, and the numbers drift apart. With one, a metric changes in one place and every consumer picks up the change, and a filter that must always apply, such as one customer’s data only, cannot be skipped.
The parts
What every semantic layer defines
- Dimensions
- Attributes you group and filter by: status, country, plan, signup date.
- Measures
- Aggregations bound to a column, such as SUM(amount) or COUNT(DISTINCT user_id).
- Metrics
- Named business numbers built from measures: revenue, average order value, retention.
- Entities and joins
- Which tables relate and how, so a query can group orders by customer country without hand-written joins.
- Time grain
- The agreed time column for each table and the grains it rolls up to: day, week, month.
- Governed filters
- Rules every query gets whether it asks or not, such as excluding test accounts or scoping to one tenant.
Example
One metric, four semantic layers
The same definition, revenue as SUM(amount) on an orders table, grouped by order status, in four tools, each with the query that reads it back. The vocabulary barely changes. What changes is where the definition lives, what can query it, and who controls access.
Where it lives
Five places a semantic layer can live
The choice that matters most is not the syntax but the location. It decides which tools can reuse the definitions, whose permissions apply, and what you have to run.
Inside a BI tool
LookML, Power BI semantic models, Tableau data sources
Consistent inside that tool. Other tools, your application code and agents usually cannot reuse the definitions.
In the warehouse
Snowflake semantic views, Databricks metric views
Definitions are database objects with the warehouse’s permissions. Anything that speaks SQL to that warehouse can use them.
Next to your transformations
dbt Semantic Layer (MetricFlow)
Metrics sit in YAML beside the models that build the tables, and a query engine compiles requests to warehouse SQL.
A standalone service
Cube, AtScale
A separate server between the database and every consumer, with its own APIs, caching and access rules.
In application code
hypequery datasets
Definitions are TypeScript or Python in your app’s repo, imported by your backend and deployed with it.
Comparison
Semantic layer options compared
Each cell was checked against the vendor’s own docs on November 10, 2026. These products changed a lot in 2026, so check the linked sources before you decide. hypequery is listed last because it is ours.
| Option | Where definitions live | How you query it | Databases | Open source and price | Access control |
|---|---|---|---|---|---|
| dbt Semantic Layer (MetricFlow) | YAML in the dbt project, next to the models | GraphQL, JDBC (Arrow Flight SQL) and Python APIs; BI integrations; dbt MCP server | Hosted: Snowflake, BigQuery, Databricks, Redshift, Postgres, Trino. MetricFlow has experimental, unreleased ClickHouse support | MetricFlow: Apache 2.0. Hosted Semantic Layer: dbt platform, Starter ($100 per user per month) and up | The warehouse credentials configured for the Semantic Layer |
| Snowflake semantic views | A schema object: SQL DDL, or YAML loaded with a system function | SEMANTIC_VIEW() clause or plain SQL with AGG(); Cortex Analyst, Cortex Agents, managed MCP server | Snowflake only | No: a Snowflake feature. Imports and exports Apache Ossie YAML | SELECT on the view; row access and masking policies on base tables propagate |
| Databricks metric views | A Unity Catalog view defined in YAML | SQL with MEASURE(); dashboards, Genie, BI tools through SQL | Databricks; the core is in Apache Spark 4.2 | Core contributed to Apache Spark (Apache 2.0) | Unity Catalog privileges; row filters and masks cannot be set on the view itself |
| Cube | A separate service with YAML or JavaScript data models | REST, GraphQL and SQL APIs; embedding SDKs | Most warehouses, including ClickHouse | Cube Core: Apache 2.0. Cube Cloud: paid plans | A security context from a signed JWT, applied through query rewrite and access rules |
| hypequery (code-defined) | TypeScript or Python files in your application repo | Function calls, a typed HTTP API, React hooks, an MCP server | ClickHouse | Apache 2.0 | A tenant key on each dataset, filled from the authenticated session; queries without it fail |
dbt Semantic Layer and MetricFlow
Semantic models, metric types and the Semantic Layer APIs, compared with a semantic layer defined in code.
Read
Snowflake semantic views
CREATE SEMANTIC VIEW, the SEMANTIC_VIEW() query and Cortex Analyst, compared with a semantic layer defined in code.
Read
Databricks metric views
Unity Catalog metric views in YAML, the MEASURE() function and Genie, compared with a semantic layer defined in code.
Read
Open Semantic Interchange (OSI)
The vendor-neutral spec for exchanging semantic models: who is behind it, what the format covers and what it leaves out.
Read
Interchange
Open Semantic Interchange, now Apache Ossie
Every option above stores definitions in its own format, which locks metrics into one tool. Open Semantic Interchange (OSI) is a vendor-neutral YAML or JSON format for semantic models, so one definition can move between tools. Snowflake launched it with partners in September 2025, the first spec was published under Apache 2.0 in January 2026, and it entered the Apache Incubator under the name Apache Ossie.
Snowflake semantic views already import and export Ossie YAML, dbt v1.12 reads Ossie files, and a separate converters repository covers dbt, Databricks, Power BI and others. Ossie describes models; it is not a query engine. The Open Semantic Interchange guide covers the spec, its members and what is still missing.
Choosing
How to choose a semantic layer
- All your data is in Snowflake or Databricks and the consumers are BI tools and the warehouse’s own AI features: start with semantic views or metric views. There is nothing extra to run.
- You already model in dbt and want one set of metrics across several BI tools: the dbt Semantic Layer keeps them next to your models.
- You need a serving layer with caching and APIs in front of any warehouse: a standalone service such as Cube.
- The metrics power your own product, behind your API and in customer-facing dashboards, with one customer’s data per request: define them in code, where your backend already authenticates users. On ClickHouse, that is what hypequery datasets do.
Questions
Semantic layer FAQ
What is a semantic layer?
A semantic layer is a shared definition of business metrics, dimensions and joins that sits between raw tables and the tools that query them. Dashboards, APIs, notebooks and AI agents ask for "revenue" by name, and the layer turns that into the right SQL, so every consumer gets the same number.
What is an example of a semantic layer?
A metric called revenue defined once as SUM(amount) on the orders table, with status and customer country as dimensions. A dashboard asking for revenue by country and an AI agent asking the same question both go through that definition. dbt MetricFlow, Snowflake semantic views, Databricks metric views, Cube and hypequery datasets are all ways to write it.
What is the difference between a semantic layer and a data warehouse?
The warehouse stores and computes the data. The semantic layer stores the meaning: which column is revenue, how tables join, which filters always apply. Some warehouses now include one, such as Snowflake semantic views and Databricks metric views, but the two jobs are still separate.
Is a metrics layer the same as a semantic layer?
Mostly. "Metrics layer" usually means the metric definitions alone. "Semantic layer" also covers entities, joins and dimensions, which a metric needs before it can be sliced.
Do AI agents need a semantic layer?
They benefit from one. An agent writing raw SQL has to guess which column means revenue and how tables join, and it can skip filters such as tenant scoping. A semantic layer gives it named metrics and enforces the filters. dbt, Snowflake, Databricks and hypequery all ship agent or MCP integrations for this reason.
What is Open Semantic Interchange (OSI)?
OSI is a vendor-neutral, Apache 2.0 spec for exchanging semantic models between tools, launched by Snowflake and partners in September 2025. It entered the Apache Incubator in 2026 and is now called Apache Ossie. It defines a file format, not a query engine.
Is there an open-source semantic layer?
Yes. MetricFlow, the engine behind the dbt Semantic Layer, is Apache 2.0. So are Cube Core and hypequery. Metric views are part of Apache Spark 4.2. The hosted dbt Semantic Layer and Snowflake semantic views are not open source.
Guides
Semantic layer guides
Each guide explains one option and maps it onto a semantic layer defined in code. For the ClickHouse side, see the ClickHouse semantic layer.
dbt Semantic Layer and MetricFlow
Semantic models, metric types and the Semantic Layer APIs, compared with a semantic layer defined in code.
Read
Snowflake semantic views
CREATE SEMANTIC VIEW, the SEMANTIC_VIEW() query and Cortex Analyst, compared with a semantic layer defined in code.
Read
Databricks metric views
Unity Catalog metric views in YAML, the MEASURE() function and Genie, compared with a semantic layer defined in code.
Read
Open Semantic Interchange (OSI)
The vendor-neutral spec for exchanging semantic models: who is behind it, what the format covers and what it leaves out.
Read
ClickHouse semantic layer
Datasets, measures and tenant keys for ClickHouse in TypeScript or Python.
Read
hypequery vs Cube
A code-first library compared with a standalone semantic layer service.
Read
Sources
Vendor pages used for this page, all read on November 10, 2026.
- dbt Labs
- docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl
- docs.getdbt.com/docs/build/latest-metrics-spec
- docs.getdbt.com/docs/use-dbt-semantic-layer/sl-faqs
- www.getdbt.com/pricing
- github.com/dbt-labs/metricflow/pull/2124
- Snowflake
- docs.snowflake.com/en/user-guide/views-semantic/overview
- docs.snowflake.com/en/user-guide/views-semantic/querying
- docs.snowflake.com/en/user-guide/views-semantic/best-practices-dev
Next step
Define a semantic layer in your own codebase
hypequery datasets are TypeScript or Python files: dimensions, measures, joins and a tenant key, served to your API, React hooks and AI agents over MCP. Open source, for ClickHouse.