Guides

How to choose a semantic layer

Semantic layers differ by where they sit relative to the warehouse and who they serve — one BI tool, every BI tool, an app, or an AI agent.

4Analytics · Published September 22, 2026

A semantic layer defines a metric — what "revenue" or "active user" means, which tables it joins, how it rolls up by time and dimension — once, so every tool that queries it gets the same number. Without one, the definition lives inside each report, each BI tool's model, or each analyst's head, and "why don't these two dashboards agree" becomes a recurring meeting. Choosing a BI tool covers where a definition can live day to day; this guide is for the moment a team decides the definition needs to live somewhere every tool — not just one BI product — can reach it.

Decide if you need this yet

A semantic layer earns its cost once more than one thing queries the same metric: two BI tools, a BI tool and a notebook, or a BI tool and an AI agent now that natural-language querying is showing up everywhere. If everyone in the company uses a single BI tool and that tool's own modeling layer (LookML, Power BI's model, a dbt-generated mart) is enough, adding a separate semantic layer is a second place to maintain the same logic, not a simplification. Add one when a second consumer of the same metrics shows up, not in anticipation of it.

Where the layer sits relative to the warehouse

  • Native to the warehouse, no data movement. AtScale and Honeydew run as a layer directly against your cloud warehouse — AtScale across Snowflake, Databricks, BigQuery and Redshift; Honeydew specifically as a native Snowflake application. Metrics are modeled once and exposed to BI clients via SQL, MDX or REST, with the query pushed down to the warehouse rather than data copied out.
  • Headless, sits between the warehouse and every consumer. Cube is explicitly tool-agnostic: the same metric definitions serve a BI tool, a custom app and a text-to-SQL layer through SQL, REST or GraphQL APIs, with Cube handling caching and pre-aggregation centrally rather than leaving each consumer to query the warehouse directly.
  • Bolted onto the transformation layer you already run. MetricFlow compiles YAML metric definitions — written alongside your existing dbt models — into SQL, and powers the dbt Semantic Layer. If you already model data in dbt, this extends work you have already done rather than adding a second modeling exercise.
  • A modeling language, not a hosted service. Malloy is a language and toolchain, not a product with an API and access controls out of the box. Analysts define reusable models and write short composable queries that compile to standard SQL, embedded in a notebook, an IDE or a custom application. It solves the "stop repeating joins" problem without taking on the "serve this to every BI tool in production" problem — that is a deliberate scope limit, not a missing feature.
  • Built for embedding in your own product, not internal BI. Propel targets product teams exposing customer-facing metrics inside their own application, not analysts querying a warehouse. It manages a ClickHouse-backed store and serves counters, time series and leaderboards through a single GraphQL endpoint — infrastructure for a feature you are shipping, not a layer under your internal dashboards.

Who else needs to read the same metrics

If the requirement is purely "our BI tools agree with each other," AtScale or Cube both solve it. If the requirement now includes AI agents or chat interfaces querying data on demand, look specifically at how a product treats that path: Honeydew markets MCP-compatible access for AI agents alongside BI as a first-class use case, aimed at preventing a chat-based analyst and a dashboard from silently reinventing the same metric differently. MetricFlow powers the dbt Semantic Layer's API, which BI tools, notebooks and agents can all query the same way, provided you are already on the dbt platform to serve it in production.

Open source vs commercial, and what "open source" gets you

Cube Core, MetricFlow and Malloy are open source and self-hostable at no licence cost. AtScale, Honeydew and Propel are commercial products with no open-source core. As with any open-source infrastructure, self-hosting buys flexibility and no licence fee at the cost of operating it yourself; each open-source option here also sells a managed cloud version (Cube Cloud; the hosted dbt Semantic Layer, part of the paid dbt platform) if you want the model without running the infrastructure.

How pricing scales

Cube Core is free to self-host, with Cube Cloud priced per developer per month. MetricFlow itself is a free Python package; serving its metrics in production at scale requires the paid dbt platform. Malloy has no vendor-hosted product or price at all — it is a language you embed. AtScale prices by the number of governed metrics and dimensions deployed rather than by seat, with no published dollar figures. Honeydew combines a per-user fee with a platform fee that scales with the number of active semantic objects. Propel is quote-only. None of these belong on a shortlist page as dollar figures — check the profile, and model cost against the number of metrics you will actually govern, not seats alone, since several of these products price that way.

A shortlist by situation

  • Multiple BI tools against one warehouse, need query acceleration too: AtScale.
  • Want one governed metric layer serving BI tools, a custom app and an AI layer from the same definitions: Cube.
  • Already modeling in dbt and want metrics as a natural extension of it: MetricFlow.
  • Snowflake-native, want one layer shared by BI dashboards and AI analyst agents: Honeydew.
  • Want reusable, DRY data models without committing to a full semantic-layer service: Malloy.
  • Building customer-facing analytics inside your own product, not internal BI: Propel.

Questions to ask vendors or in a trial

  1. Does the query get pushed down to our warehouse, or does data get copied into the semantic layer's own store?
  2. Which BI tools, notebooks and AI interfaces can query this layer today, versus on a roadmap?
  3. How is a metric change tested and rolled out — can we see what breaks before it reaches a dashboard?
  4. What happens to query performance and warehouse cost as the number of governed metrics grows?
  5. If we stop paying for the managed product, what do we keep — is the modeling layer portable?

Common mistakes

Adding a semantic layer before more than one consumer actually needs the same metric — until then, it is a second place to maintain logic your BI tool or dbt project already holds. Choosing a product built for internal BI to power a customer-facing feature, or the reverse. And assuming a semantic layer alone fixes disagreement between teams — it enforces one definition, but someone still has to agree what that definition should be, which is a governance conversation, not a purchasing decision.

See AtScale vs Cube and MetricFlow vs Honeydew for two direct match-ups, choosing a BI tool for how this connects to the front end, and browse every tool in this category.

Related tools

AtScale Universal semantic layer that models metrics once on top of a cloud data warehouse and exposes them to any BI tool without data movement. Cube Open-source headless semantic layer that defines metrics once and serves them via SQL, REST, and GraphQL APIs to any BI tool or app. MetricFlow Open-source engine that compiles YAML metric definitions into SQL, and powers the dbt Semantic Layer. Honeydew Snowflake-native semantic layer that compiles governed metric and dimension definitions for BI tools and AI agents. Malloy Open-source modeling and query language that compiles to SQL, letting analysts define reusable metrics and explore data without repeating joins. Propel GraphQL metrics API platform for embedding customer-facing analytics and reports directly into a product.

Terms used in this guide

Semantic layer A layer that defines business metrics and dimensions once, centrally, so every tool and report uses the same numbers. Business intelligence (BI) The practice of turning company data into dashboards, reports and metrics that guide business decisions. Data modeling The practice of organizing data into entities, relationships and schemas that make it accurate and efficient to query. OLAP (online analytical processing) A category of technology optimized for fast, multi-dimensional aggregation and slicing of data for analysis. Text-to-SQL Technology that translates a plain-language question directly into a runnable SQL query against a database. Embedded analytics Charts, reports or dashboards built directly into another application instead of a separate BI tool.

Latest on this topic