--- title: "dbt Semantic Layer vs Cube: Where Each Fits" url: "https://atlan.com/know/ai-agent/semantic-layer/dbt-semantic-layer-vs-cube/" description: "dbt Semantic Layer defines metrics inside one dbt project. Cube serves them headlessly to any tool, dbt or not. Here is where each actually fits." author: "Emily Winks" author_role: "Data Governance Expert" published: "2026-09-10" updated: "2026-09-10T00:00:00.000Z" --- --- 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: a headless layer that can read a dbt project directly or ignore dbt entirely, serving the same metric over SQL, REST, GraphQL, MDX/DAX, and now MCP. Seventeen vendors, including Cube, dbt Labs, and Atlan, signed the Open Semantic Interchange initiative in 2025 to standardize how a metric gets written down[1], evidence 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](https://atlan.com/know/ai-agent/semantic-layer/semantic-layer-vs-data-catalog/) and the three-way split in [context layer vs data catalog vs semantic layer](https://atlan.com/know/ai-agent/semantic-layer/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, headless semantic layer independent of any single transformation tool | | Requires a dbt project | Yes, by design | No, though the cube_dbt integration reads one directly | | Licensing floor | dbt Cloud 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, REST, GraphQL, MDX/DAX, 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](https://atlan.com/know/semantic-layer-vs-traditional-data-marts/) and [ontology vs semantic layer](https://atlan.com/know/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 headless one, is what [Lightdash vs dbt Semantic Layer vs Atlan's context layer](https://atlan.com/know/ai-agent/semantic-layer/lightdash-vs-dbt-semantic-layer-vs-context-layer/) answers for a different pair of tools. Community discussion tends to land here too. An independent three-way breakdown of warehouse-native, dbt-based, and Cube-based semantic layers concludes that none of the three architectures is strictly better, each optimizes for a different point in the pipeline[2]. That framing 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 YAML format a metric is written in, which is what the Open Semantic Interchange initiative actually does, does not resolve that: it makes the format portable, not the ownership. [Semantic layers failed, and context graphs are next](https://atlan.com/know/semantic-layers-failed-context-graphs/) makes an adjacent version of that argument at greater length than this page needs. --- ## What is dbt Semantic Layer? dbt Semantic Layer is a headless, 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[3]. That sits inside a bigger shift: dbt's new Fusion engine, a Rust rewrite of the Python engine that has powered dbt Core since v1.x, now powers both dbt Core and the commercial Fusion distribution as of dbt v2.0[4], a different codebase from the one [dbt Semantic Layer for metrics definition](https://atlan.com/dbt-semantic-layer/) covers in more depth. The Semantic Layer is not a dbt Core feature. It requires at minimum a dbt Cloud Starter plan, priced at $100 per user monthly, unlocking what dbt calls "Semantic Layer basic"[5]. What that floor buys has grown: dbt now lists native, generally available integrations spanning Tableau, Power BI, Excel, Hex, Mode, and Omni, plus JDBC and GraphQL options 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 Cloud deployment:** metrics are built and served through a dbt job, gated behind a Starter plan or higher - **Native BI connectors:** Tableau, Power BI, Excel, and a growing partner list query the same served definition directly --- ## What is Cube? Cube, marketed as Cube Core and Cube Cloud, is a headless semantic layer built to sit between a warehouse and whatever tool queries it, independent of any single transformation tool. Cube Core is open source, dual-licensed under MIT for the client libraries and Apache 2.0 for the backend, and the [cube-js/cube repository](https://github.com/cube-js/cube) has attracted roughly 20,600 GitHub stars. Bain Capital Ventures' analysis of Cube's 2024 funding round found Cube powers data experiences at roughly 20% of the Fortune 1000[7]. Pricing runs a genuine free tier with semantic modeling included, up through paid per-developer plans and Enterprise contracts[8], a lower floor than dbt Semantic Layer's Starter plan. Cube's architecture and real limitations get a fuller treatment at [What Is Cube Semantic Layer](https://atlan.com/know/ai-agent/semantic-layer/cube-semantic-layer/), not repeated here. Cube's dbt relationship is optional. The cube_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[9]. A team without dbt can model directly against the warehouse instead, the structural difference this page keeps returning to. Cube's multi-API layer, SQL, REST, GraphQL, MDX/DAX, and an **MCP Server**, is what [why MCP matters for AI agents](https://atlan.com/know/mcp/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](https://atlan.com/know/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 via cube_dbt - **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 enforced inside Cube itself, checked at query time - **Multi-API layer:** the same metric served over SQL, REST, GraphQL, MDX/DAX, 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-book --- ## dbt 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 dbt via cube_dbt 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 | | Governance and lineage | Not built in; inherits dbt's own version control | Not built in; access control only, no ownership or certification tracking | | Licensing floor | dbt Cloud 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[8], 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 The cube_dbt integration is the concrete mechanism: it loads a dbt project's manifest.json and exposes `dbt_models` and `dbt_model` functions a Cube data model can iterate over in Jinja templates, rendering dbt's own models as cubes enriched with measures, joins, and pre-aggregations[9]. A team running this pattern keeps transformation logic in dbt, where [dbt data lineage](https://atlan.com/know/ai-agent/data-for-ai/data-lineage-for-ai/) 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](https://atlan.com/know/regovern-building-semantic-layer-guide/) covers for either approach alone, and different from the conflation [semantic layer vs metrics layer](https://atlan.com/know/ai-agent/semantic-layer/semantic-layer-for-analytics/) 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 MDX/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](https://atlan.com/know/ai-agent/semantic-layer/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](https://atlan.com/know/ai-agent/semantic-layer/semantic-layer-for-bi-vs-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 Assessment --- ## How Atlan approaches metric governance across dbt Semantic Layer and Cube Both tools answer what a metric means and how to calculate it, and both answer that question well within the boundary they own. Neither answers who owns a given definition, whether it is still valid, or what breaks downstream if someone changes it, and that is not a gap specific to either product; it is what [semantic understanding vs metadata management](https://atlan.com/know/ai-agent/semantic-layer/semantic-understanding-vs-metadata-management/) calls the second layer a semantic layer alone was never built to provide. Atlan is the [context layer](https://atlan.com/know/what-is-context-layer/) for AI. Its [Enterprise Data Graph](https://atlan.com/know/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](https://atlan.com/know/ai-readiness/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](https://atlan.com/know/mcp-delivers-business-context/) 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](https://atlan.com/know/what-is-atlan-mcp/) and [MCP-connected data catalog](https://atlan.com/know/mcp-connected-data-catalog/). [Why AI agents need an enterprise context layer](https://atlan.com/know/why-ai-agents-need-an-enterprise-context-layer/) treats ownership as a distinct purchase from either semantic layer, and [data catalog vs context layer](https://atlan.com/know/data-catalog-vs-context-layer/) and [active metadata vs context layer](https://atlan.com/know/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 Readiness --- ## The governance question dbt Semantic Layer and Cube don't answer 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. Neither answers who is accountable for that metric once more than one team, tool, or agent depends on it. Seventeen vendors agreeing to standardize how a metric is written down is real progress on portability, not the same as deciding 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. Book a Demo --- ## 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 a headless 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, cube_dbt, is optional: it reads a dbt project's manifest file and renders dbt models as cubes for teams reusing definitions already written in dbt. ### 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. ### 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, REST, GraphQL, and MDX/DAX, so any tool speaking one of those protocols connects without a dedicated connector. ### 5. Does either dbt Semantic Layer or Cube handle metric governance or ownership? Not on their own. Both define what a metric means and calculate it consistently, a different job from tracking who owns a definition or what breaks downstream if it changes. That question sits in a governance or context layer above either tool. ### 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 the widest protocol surface, including MDX/DAX, matters more than native BI connectors. --- ## Sources 1. [Snowflake, Salesforce, dbt Labs, and More, Revolutionize Data Readiness for AI with Open Semantic Interchange Initiative, Snowflake](https://www.snowflake.com/en/news/press-releases/snowflake-salesforce-dbt-labs-and-more-revolutionize-data-readiness-for-ai-with-open-semantic-interchange-initiative/) 2. [Semantic Layer Architectures Explained: Warehouse-Native vs dbt vs Cube, Typedef.ai](https://www.typedef.ai/resources/semantic-layer-architectures-explained-warehouse-native-vs-dbt-vs-cube) 3. [dbt Licensing FAQ, dbt Labs](https://www.getdbt.com/licenses-faq) 4. [dbt Labs Delivers Significant Cost Optimization Results and Agentic AI Features, Powered by Fusion, PR Newswire](https://www.prnewswire.com/news-releases/dbt-labs-delivers-significant-cost-optimization-results-and-agentic-ai-features-powered-by-fusion-302583718.html) 5. [dbt Cloud Pricing, dbt Labs](https://www.getdbt.com/pricing) 6. [Available Integrations, dbt Developer Hub](https://docs.getdbt.com/docs/platform-integrations/avail-sl-integrations) 7. [How Cube Is Unlocking a New Generation of AI Apps With Its Universal Semantic Layer, Bain Capital Ventures](https://baincapitalventures.com/insight/how-cube-is-unlocking-a-new-generation-of-ai-apps-with-its-universal-semantic-layer/) 8. [Cube Pricing, Cube](https://cube.dev/pricing) 9. [Using Cube With dbt, Cube Documentation](https://docs.cube.dev/recipes/data-modeling/dbt)