dbt Semantic Layer and Cube solve the same problem, one metric calculated five different ways in five dashboards, from two different starting points. dbt Semantic Layer builds metrics inside a dbt project and serves that definition through MetricFlow to whichever tool asks. Cube starts outside any one project: an open-source semantic layer that can read a dbt project directly or ignore dbt entirely, serving the same metric over SQL, DAX, REST, GraphQL, and now MCP. The cross-vendor standard for writing a metric down, formerly Open Semantic Interchange, is now Apache Ossie, and dbt Labs published the first version of its specification with its partners on 2026-01-29[1]. The fragmentation problem is real, not invented for this comparison.
The rest of this page treats dbt Semantic Layer and Cube as different answers to where a metric gets defined and served. Atlan’s context layer, covered in semantic layer vs data catalog and the three-way split in context layer vs data catalog vs semantic layer, answers a later question: whichever tool defines a metric, who owns it, and who can query it.
| Dimension | dbt Semantic Layer | Cube |
|---|---|---|
| What it is | A metrics layer built into dbt, powered by MetricFlow | An open-source semantic layer inside Cube’s agentic analytics platform, independent of any single transformation tool |
| Requires a dbt project | Yes, by design | No, though the dbt integration reads one directly on Premium and above |
| Licensing floor | dbt platform Starter at $100/user/month for “Semantic Layer basic” | A free tier includes semantic modeling; Cube Core is open source and self-hostable |
| Query interface | GraphQL, JDBC, ADBC, and a Python SDK | SQL, DAX, REST (JSON), GraphQL, and an MCP Server |
| Caching | Declarative caching plus scheduled Exports into the warehouse | A two-level cache plus Cube Store, a dedicated Rust-based OLAP engine |
| Governance | Version-controlled definitions, git-based change review | Row- and column-level access control enforced at query time |
dbt Semantic Layer vs Cube: what’s the difference?
The real distinction is when and where a metric gets defined, not which tool calculates it more correctly. dbt Semantic Layer ties metric definitions to the transformation layer itself: a semantic model is built on top of dbt models already in the project, compiled by MetricFlow, and deployed the same way a dbt job deploys anything else. Cube is architected around the opposite assumption, that a metric’s definition should not depend on which transformation tool a team happens to run. That is also why semantic layer vs traditional data marts and ontology vs semantic layer are different questions from this one, both about what a semantic layer is in general, not which architecture a specific pair of tools chose. The same architectural question, applied to a BI-native layer instead of a warehouse-independent one, is what Lightdash vs dbt Semantic Layer vs Atlan’s context layer answers for a different pair of tools.
Neither architecture is strictly better. Each optimizes for a different point in the pipeline, and that matters here specifically: a metric defined once inside dbt and a metric served once through Cube can both be correct and still disagree, if a second copy of the same logic exists somewhere else in the stack. Standardizing the format a metric is written in, which is what Apache Ossie does, makes the format portable. It does not make the ownership portable. Semantic layers failed, and context graphs are next makes an adjacent version of that argument at greater length than this page needs.
What is dbt Semantic Layer?
dbt Semantic Layer is an API-served metrics layer built on MetricFlow, designed to define a metric once inside a dbt project and serve that definition to every downstream tool that asks. MetricFlow was relicensed from a Business Source License to Apache 2.0 in October 2025, a move dbt Labs frames as letting AI agents build on a transparent engine for governed conversational analytics[2]. That sits inside a bigger shift. On 2026-06-01 dbt Labs put the Rust Fusion engine behind both v2 distributions, and dbt v2 went generally available on 2026-09-16, when Fusion became simply dbt, dbt Core v2 became dbt OSS, and dbt Cloud became the dbt platform[3]. dbt v1, the Python generation, stays maintained; 1.13 is the last minor release to add meaningful functionality to that codebase. dbt Semantic Layer for metrics definition covers the engine in more depth.
The Semantic Layer is not an open-source feature. dbt’s docs state the gate plainly: defining and querying metrics with the dbt Semantic Layer requires a dbt platform Starter or Enterprise-tier account[5]. Starter is priced at $100 per user monthly and includes what dbt calls “Semantic Layer basic”[4]. What that floor buys has grown: dbt now lists native, generally available integrations spanning Tableau, Power BI, Excel, Hex, Mode, and Omni, plus JDBC, ADBC, and GraphQL APIs and a Python SDK for anything without a dedicated connector[6]. That reach is the real strength: a metric defined once inside dbt already has a growing bench of vendor-maintained connectors.
Core components of dbt Semantic Layer
- Semantic models and metrics: defined as code inside the dbt project, alongside the transformations that build the underlying tables
- MetricFlow: the query engine, now Apache 2.0, that compiles a metric request into the correct SQL against the warehouse
- dbt platform deployment: metrics are built and served through a dbt job, gated behind a Starter or Enterprise-tier account
- Native BI connectors: Tableau, Power BI, Excel, and a growing partner list query the same served definition directly
What is Cube?
Cube describes itself as the agentic analytics platform for business intelligence and embedded analytics, built on an open-source semantic layer that sits between a warehouse and whatever tool queries it, independent of any single transformation tool. Cube Core is the self-hostable open-source piece, dual-licensed under MIT for the client libraries and Apache 2.0 for the backend, and the cube-js/cube repository carries 20.9k stars and 2.1k forks, checked 2026-09-18. Pricing runs a free tier with semantic modeling included, Starter at $40 and Premium at $80 per developer per month, and custom Enterprise contracts; on Premium and above Cube also prices Explorer seats at $40 and Viewer seats at $20 a month[7], a lower entry point than the dbt platform Starter plan. Cube’s architecture and real limitations get a fuller treatment at What Is Cube Semantic Layer, not repeated here.
Cube’s dbt relationship is optional. The dbt integration loads a dbt project’s manifest.json and renders the selected models as cubes, which the modeling layer then enriches with measures and joins; Cube documents that pull direction on Premium plans and above, and the reverse, dbt push, as still in preview[8]. A team without dbt can model directly against the warehouse instead, the structural difference this page keeps returning to. Cube’s MCP server exposes 30 tools, covering query and discovery, dashboard authoring, data-model editing, committing and publishing changes, and pre-aggregation builds, on Premium and Enterprise plans for a Viewer role or higher[9]. Cube’s multi-API layer, SQL, DAX, REST, GraphQL, and that MCP Server, is what why MCP matters for AI agents treats as a category shift: an agent querying a governed metric fails differently than one guessing at raw tables, the same argument RAG accuracy problems makes about retrieval.
Core components of Cube
- Data modeling: cubes, measures, and dimensions defined in YAML or Python, either standalone or generated from a dbt project
- Caching: an in-memory layer plus Cube Store, a Rust-based distributed OLAP engine, for materialized pre-aggregations
- Access control: row- and column-level security and access policies enforced inside Cube itself, checked at query time
- Multi-API layer: the same metric served over SQL, DAX, REST (JSON), GraphQL, and MCP
Inside Atlan AI Labs and the 5x accuracy factor
See how explicit semantic context, not just a bigger model, closed the accuracy gap in real production systems, with a repeatable playbook behind it.
Download the E-bookdbt Semantic Layer vs Cube: head-to-head
The sharpest differences show up in what each tool assumes about the transformation layer underneath it, and in how far a licensing dollar reaches before a team hits a paywall.
| Aspect | dbt Semantic Layer | Cube |
|---|---|---|
| Primary focus | Metric consistency across tools connected to one dbt project | Metric consistency and performance across any warehouse, dbt-based or not |
| Transformation dependency | Requires an existing dbt project and its models | Optional; reads a dbt manifest on Premium and above, or models the warehouse directly |
| Time to first metric | Fast for teams already writing dbt models | Fast for teams without dbt; a small extra step for teams reusing dbt models |
| Performance approach | Relies on warehouse query performance plus scheduled Exports | Purpose-built two-level cache and Cube Store pre-aggregations |
| Documented governance scope | Metric definitions versioned as code and reviewed in git | Row- and column-level security and access policies enforced at query time |
| Licensing floor | dbt platform Starter, $100 per user per month | Free tier available; Cube Core is fully open source to self-host |
| Best for | Teams standardizing metrics across an existing dbt-centric stack | Embedded analytics, dashboard performance, or a non-dbt transformation layer |
Two data points sharpen that table. dbt Semantic Layer’s own integration list already runs to Tableau, Power BI, Excel, Hex, Mode, and Omni with native connectors[6], wider than a year-old comparison would find. Cube’s free tier, by contrast, already includes semantic modeling, not just a trial[7], which changes the calculus for a budget-constrained team.
Do you need both dbt Semantic Layer and Cube?
Most teams end up choosing one as the primary metrics layer, not running both as equals, because the two solve overlapping jobs. The more common pattern is dbt Semantic Layer or Cube as the metric source of truth, with the other tool either absent or serving a narrower, adjacent role, such as Cube handling embedded analytics performance on top of metrics dbt already defines.
How they work together
Cube’s dbt integration is the concrete mechanism: every pull converts a dbt manifest into cube definitions, which the Cube data model then enriches with measures, joins, and pre-aggregations. Cube documents it on Premium plans and above, alongside a cube_dbt Python package and a dbt-sync API[8]. A team running this pattern keeps transformation logic in dbt, where dbt data lineage already traces a model to its source tables, while getting Cube’s caching and API surface for whatever consumes the metric next. That is narrower than what how to build an AI-ready semantic layer covers for either approach alone, and different from the conflation semantic layer vs metrics layer names.
When should you add Cube on top of dbt Semantic Layer?
The right call depends on how much of the load is embedded analytics and how many tools outside dbt’s native connector list need the same metric.
Stay with dbt Semantic Layer alone when the team is already deep in dbt, the connected tools are Tableau, Power BI, Excel, or another tool on dbt’s native integration list, and query volume is light enough that warehouse-level performance is already acceptable.
Add Cube when dashboard traffic is heavy enough that pre-aggregated caching meaningfully cuts warehouse cost, a tool needs DAX or a protocol dbt does not natively serve, or the transformation layer underneath is not dbt at all, per text-to-SQL vs semantic layer for self-serve analytics, a related decision about how far to push either approach.
Consider Cube instead of dbt Semantic Layer when dbt is not the team’s transformation tool, the free-tier entry point matters more than native BI connectors, or semantic layer for BI vs semantic layer for AI agents surfaces a use case leaning toward Cube’s broader protocol surface.
Is your metric layer actually governed?
Run a quick assessment to see whether the metrics your team defines in dbt, Cube, or elsewhere are still tracked, owned, and validated once they ship.
Take the AssessmentHow Atlan approaches metric governance across dbt Semantic Layer and Cube
Both tools answer what a metric means and how to calculate it, and both document that scope clearly: dbt versions definitions as code, Cube enforces row- and column-level security at query time. Who owns a given definition, whether it is still valid, and what breaks downstream when it changes are a second layer, the one semantic understanding vs metadata management describes. Atlan carries ownership, lineage, and validation for metrics defined in dbt, in Cube, and anywhere else.
Atlan is the context layer for AI. Its Enterprise Data Graph ingests metric definitions from dbt Semantic Layer, Cube, and any other semantic layer a team runs, as first-class assets with lineage traced back to the warehouse tables underneath them, so ownership, certification, and access policy travel with a metric regardless of which tool authored it. That connection matters because role of metadata management in enterprise AI is shifting from storing definitions toward arbitrating between them, exactly the situation a team running both dbt Semantic Layer and Cube at once creates by design.
The MCP server is the delivery mechanism: an agent asking for “revenue” gets the same governed context whether the calculation lives in MetricFlow or a cube, per what is Atlan MCP and MCP-connected data catalog. Why AI agents need an enterprise context layer treats ownership as a distinct purchase from either semantic layer, and data catalog vs context layer and active metadata vs context layer both draw the same line between defining a metric and being accountable for it.
See if your agents already know too much, or too little
Run through the checklist enterprise teams use to find gaps before scaling AI agents on top of any semantic layer.
Check Your ReadinessWhere metric ownership lives once both tools are in play
dbt Semantic Layer and Cube both answer where a metric gets defined and how it reaches the tools that need it, one tied to the transformation layer, one deliberately independent of it. Accountability for that metric, once more than one team, tool, or agent depends on it, is a separate decision. Apache Ossie standardizes how a metric is written down, which is real progress on portability. It does not settle who gets to change the number, and enterprises running AI agents against either tool are finding that out earlier than a dashboard-only team would.
FAQs about dbt Semantic Layer vs Cube
1. What is the difference between dbt Semantic Layer and Cube?
dbt Semantic Layer defines metrics inside a dbt project and serves them through MetricFlow’s API. Cube is an open-source semantic layer built to sit between a warehouse and any consuming tool, and it does not require a dbt project. The difference is architectural, transformation-time versus query-time, not which one calculates a metric correctly.
2. Does Cube require a dbt project to work?
No. Cube can model directly against a warehouse using its own YAML or Python modeling layer. The dbt integration is optional: it reads a dbt project’s manifest file and renders dbt models as cubes for teams reusing definitions already written in dbt, on Premium plans and above.
3. Can dbt Semantic Layer and Cube be used together?
Yes. Cube’s dbt integration is built for exactly this: it loads a dbt project’s manifest.json and renders the selected models as cubes, so a team keeps transformation logic in dbt and gets Cube’s caching and API layer without redefining metrics twice. Cube documents the pull direction on Premium and above; dbt push is still in preview.
4. Which one has better BI tool support, dbt Semantic Layer or Cube?
Both reach a wide set of tools through different mechanisms. dbt Semantic Layer ships native connectors for Tableau, Power BI, Excel, Hex, Mode, and Omni. Cube exposes the same metric over SQL, DAX, REST (JSON), and GraphQL, so any tool speaking one of those protocols connects without a dedicated connector.
5. How do dbt Semantic Layer and Cube document metric governance?
Each documents a different scope. dbt versions metric definitions as code and reviews changes in git. Cube documents row- and column-level security and access policies enforced at query time. Ownership, certification, and lineage that travel with a metric across every tool that defines it are a separate job, and that one belongs to a context layer.
6. When should a team choose Cube over dbt Semantic Layer, or the reverse?
Choose dbt Semantic Layer when a team is deep in dbt and wants metrics defined alongside the transformations that build them. Choose Cube when embedded analytics performance matters, dbt is not the transformation layer, or a wide protocol surface, including DAX and Cube’s Excel and Sheets connectors, matters more than native BI connectors.
