Cube’s semantic layer, like AtScale’s and Snowflake’s own Semantic Views, sits in what one recurring industry framing calls the “metric-governance camp”: tools that define a number once and serve it everywhere, over SQL, REST, GraphQL, and now MCP. What none of them do on their own is govern that number once it ships, which is why a separate “context-layer camp,” Atlan among them, exists at all. Cube’s own open-source core has real, credited adoption, a tool whose own in-layer catalog governs discovery and lineage only up to its own deployment boundary. This page goes past that general framing, already covered on the Cube semantic layer architecture page, and into how Atlan’s own connector closes the gap mechanically for a live Cube deployment.
| What It Is | Key Benefit | Best For | Status | Cataloged Objects | Lineage Scope |
|---|---|---|---|---|---|
| Atlan’s native connector for Cube’s semantic layer | Cube’s metrics become one governed, agent-reachable asset instead of a silo | Teams running Cube alongside other cataloged warehouses, dbt models, or BI tools | Private Preview since 2026-08-17 | Cubes, views, dimensions, measures, segments | Upstream warehouse tables/columns through Cube’s model |
What does Cube’s headless semantic layer do, and where does it stop?
Permalink to “What does Cube’s headless semantic layer do, and where does it stop?”Cube (marketed as Cube.js, Cube Core, and Cube Cloud) is a headless BI tool: it defines measures, dimensions, and joins once and serves them over SQL, REST, GraphQL, and an MCP server built for AI agents, the same “define once, query everywhere” model that has attracted roughly 20,800 GitHub stars and 2,100 forks to Cube Core, live-checked September 2026. It’s one of several tools on any current list of best semantic layer tools, and the distinction that matters here isn’t which one wins; it’s what the whole category, headless or not, leaves out. According to Cube’s own documentation, that model defines and serves metrics. It does not, on its own, say who owns a given number or whether it is still valid. Cube’s own answer to that question is its Semantic Catalog feature, an in-layer discovery view showing lineage and impact analysis inside Cube’s own deployment. That’s a genuine answer for teams that only run Cube, but it stops at Cube’s own boundary, which is a different boundary than the one a semantic layer vs data catalog comparison usually draws. It cannot see the warehouse tables a cube is built from or the systems downstream of it, and neither can it resolve whether Cube’s own Semantic Catalog has moved past preview since its June 2024 launch; that status is genuinely unresolved in Cube’s own public materials, so this page does not assert it either way. That same metric-governance/context-layer split is the throughline in how ontology and semantic layer get compared, and in how a context layer differs from a semantic layer more broadly. For the full architecture walkthrough and the general governance argument, see Cube Semantic Layer: Architecture, Adoption, and Gaps. This page assumes that context and goes straight to how a governed catalog closes the gap mechanically.
| Attribute | Details |
|---|---|
| Platform | Cube (Cube Core, Cube Cloud) |
| Integration type | Native connector, Atlan’s Cube App (Discovery + Lineage) |
| Setup complexity | Medium. Private Preview stage, access request required; exact role and permission scope is not yet publicly documented |
| Prerequisites | A reachable Cube deployment; the upstream warehouse already cataloged in Atlan; Private Preview access granted |
| Capabilities enabled | Discovery and lineage for cubes, views, dimensions, measures, and segments. Not yet enabled: Browser Extension, Self-Deployed Runtime, Enrichment, Popularity, Run-status |
| Time to value | Not yet publicly documented at Private Preview stage |
| Documentation | Atlan’s Cube App connector docs |
How does Atlan’s Cube App connector work?
Permalink to “How does Atlan’s Cube App connector work?”The connector reads Cube’s own semantic model as a live source, not a one-time export, and resolves lineage back through the warehouse tables the model is built from. Per Atlan’s own connector documentation, it catalogs a Cube semantic layer’s cubes, views, dimensions, measures, and segments along with their definitions, and traces lineage from the upstream warehouse tables. That single capability description names both halves of the mechanism.
The first half is discovery: cubes, views, dimensions, measures, and segments come in as first-class cataloged assets, each carrying its own definition, so a data team or an agent searching Atlan finds a Cube metric the same way it finds a warehouse table or a dbt model. The second half is lineage, and it’s the specific capability that stops at Cube’s own deployment boundary in Cube’s Semantic Catalog: the connector traces the path from a literal upstream warehouse table or column, through Cube’s model, to the metric a dashboard or agent ultimately reads.
Once cataloged, a Cube semantic model becomes one governed input into Atlan’s Enterprise Data Graph, alongside more than 100 other connectors, so an agent reasoning about a Cube metric can also see everything else in the estate that metric touches, not just what Cube’s own multi-API layer happens to expose. That’s the same principle behind an MCP-connected data catalog: the catalog, not any single semantic layer, is what an agent actually queries through Atlan’s own MCP server. That context lives in Atlan’s Context Lakehouse, an Iceberg-native, bring-your-own-cloud store, independent of Cube’s own deployment. Cube’s Semantic Catalog lives and dies with Cube; the governed version of the same information survives a platform change because it was never stored inside Cube in the first place, the same durability argument covered in how a data catalog compares to a context layer more broadly. The mechanism is real and citable, not a hypothetical: it’s a live connector two named customers already run, not a theoretical integration this page is arguing for. One metric definition an agent can trust is exactly what a governed data catalog for AI is built to answer for teams asking this question about a metric layer, not just a catalog, and it’s the same question raised when a data catalog doubles as an LLM’s knowledge base.
The AI context stack, explained
See where a semantic layer like Cube fits in the full stack an AI agent depends on, and what's missing when that stack stops at metric definitions.
Get the AI Context Stack BriefWhat does the Cube App connector ingest, and how does it compare?
Permalink to “What does the Cube App connector ingest, and how does it compare?”Three tools now touch the same question, cataloging Cube’s semantic model, and each draws its scope differently. Cube’s own Semantic Catalog covers discovery, lineage, and impact analysis, but only inside Cube’s own deployment. DataHub’s native Cube ingestion source, live-checked September 2026, ingests cubes as datasets, views as semantic models, and measures and dimensions as schema fields, plus tags, glossary terms, owners, and domains through its meta_mapping configuration, resolving view-to-cube column lineage and cube-to-warehouse lineage. Atlan’s Cube App connector covers the same object types as first-class governed assets, folded into the broader Enterprise Data Graph rather than a catalog-side ingestion alone.
| Scope | Cube’s own Semantic Catalog | DataHub Cube ingestion source | Atlan Cube App connector |
|---|---|---|---|
| Cubes, views, dimensions, measures, segments | Yes, native, in-layer | Yes, mapped to datasets, semantic models, and schema fields | Yes, as first-class cataloged assets with definitions |
| Tags, glossary terms, owners, domains | Not applicable, in-layer only | Yes, via meta_mapping |
Part of the broader Enterprise Data Graph’s ownership and glossary model |
| Lineage scope | Inside Cube’s deployment only | View-to-cube and cube-to-warehouse lineage | Warehouse table/column through Cube’s model, in one governed graph alongside 100+ other connectors |
| Usage stats, query profiling, pre-aggregations | Partial, in-layer | Explicitly not ingested | Not yet supported |
| Reaches beyond Cube’s own deployment | No | Catalog-side only | Yes, the same governed context is reachable by any agent via MCP, A2A, SQL, and API |
None of these three tools is wrong about what it covers. The honest distinction is what happens once a metric needs to be understood alongside everything else an agent has to reason about, not just alongside other Cube objects or other catalog entries, the same distinction that shows up when comparing Cube against dbt’s own Semantic Layer or against Snowflake Semantic Views: three different tools solving the same modeling problem, none of them solving the governance problem on its own. It’s also the reason a broader look at agent context layer tools compared treats a semantic layer as one input among several, not the whole answer, and why the same pattern repeats once metrics live in Databricks: Unity Catalog’s own metrics layer faces the identical question of who governs a metric definition once it’s served to more than one consumer. A semantic layer, headless or not, is also a step up from the traditional data marts it replaced, but replacing a data mart with a semantic layer doesn’t retroactively add governance either; it just moves the same open question one layer up the stack.
The connector’s current scope is also worth stating plainly rather than rounding up:
| Capability | Status |
|---|---|
| Discovery | Supported |
| Lineage | Supported |
| Browser Extension | Not yet supported |
| Self-Deployed Runtime | Not yet supported |
| Enrichment | Not yet supported |
| Popularity | Not yet supported |
| Run-status | Not yet supported |
A Private Preview connector that only claims two capabilities and names five gaps plainly is a more trustworthy signal than one that implies parity with a mature, generally available integration it hasn’t earned yet.
What does this give agents that a BI tool doesn’t get?
Permalink to “What does this give agents that a BI tool doesn’t get?”The real payoff of cataloging a Cube deployment is what becomes reachable by an agent that has to reason about a Cube metric alongside everything else in the estate, more than any nicer UI for human analysts. That’s the same shift covered in how teams actually build an AI agent harness: the harness is only as good as the context it can reach, and a metric locked inside one tool’s own API is context an agent can’t get to.
Discovery across the estate
Permalink to “Discovery across the estate”A metric defined in Cube becomes searchable next to every other connector Atlan catalogs, not siloed inside Cube’s own UI. An agent or analyst looking for “monthly active users” finds the Cube definition alongside the dbt model and the warehouse table it ultimately reads from, instead of having to know in advance which tool owns the answer, the same discovery problem a data catalog built for AI agents exists to solve across every connected system, not just one.
Cross-system lineage and impact analysis
Permalink to “Cross-system lineage and impact analysis”An analyst or agent changing a warehouse column can see every Cube metric that column feeds, and the reverse: a Cube metric drifting from its source is visible upstream, not just downstream inside Cube’s own dashboards. That’s the cross-system lineage Cube’s Semantic Catalog cannot see by design, because it stops at Cube’s own boundary, and it’s a concrete instance of the broader argument for implementing an enterprise context layer for AI: lineage that stops at one tool’s edge isn’t lineage an agent can fully trust. The same lineage graph is also what a context graph makes queryable once it exists, distinct from a knowledge graph built for a narrower purpose.
Governed agent delivery via MCP
Permalink to “Governed agent delivery via MCP”Cube ships its own MCP server, and it hands an agent a metric definition, one instance of why MCP matters for AI agents generally. Atlan’s MCP, alongside A2A, SQL, API, vector, and graph surfaces, hands the same agent that definition plus its ownership, freshness, lineage, and policy context. That distinction, governed versus ungoverned agent access, is the one that actually separates the two camps once every semantic layer ships its own MCP server: not whether an agent can reach a metric, but whether it can trust what it’s reaching, which is the practical difference between context engineering done deliberately and an agent left to improvise against whatever API happens to answer first.
Setting up the Cube App connector with Atlan
Permalink to “Setting up the Cube App connector with Atlan”Setup starts with a Private Preview access request, moves through a Cube-reachable crawl configuration, and ends with a metadata sync that resolves lineage against an already-cataloged warehouse.
Prerequisites:
- [ ] Cube deployment reachable by Atlan (Cube Cloud or self-hosted Cube Core)
- [ ] The upstream warehouse already cataloged in Atlan, since lineage resolves against existing warehouse assets
- [ ] Private Preview access granted for the Cube App connector
- [ ] An Atlan workspace with admin access to configure a new connector
Setup steps (conceptual; verify exact credential and permission scope against Atlan’s own connector documentation before configuring, since those details are not yet public at Private Preview stage):
- Request Private Preview access for the Cube App connector.
- Configure connectivity, pointing Atlan at the Cube deployment’s metadata endpoint.
- Run the initial crawl to catalog cubes, views, dimensions, measures, and segments.
- Confirm lineage resolution, checking that cataloged Cube assets show incoming lineage from the already-cataloged warehouse tables.
Validation checklist:
- [ ] Atlan shows the Cube connection as active
- [ ] Cubes, views, dimensions, measures, and segments appear as cataloged assets with definitions
- [ ] The lineage graph shows warehouse table/column connections into the Cube model
- [ ] A known Cube metric is discoverable via Atlan search alongside non-Cube assets
This connector is still in Private Preview, so the setup above is thinner on exact commands than a generally available integration would warrant. That’s a deliberate choice: naming what isn’t public yet is more useful to a reader evaluating the connector today than a fabricated code block would be. The team running this setup is usually the same one this integration is built for in the first place, the data and analytics engineers who own the warehouse Cube sits on top of, which is exactly the audience a context layer for data engineering teams is built to serve.
Customer proof: governing metric definitions beyond one tool
Permalink to “Customer proof: governing metric definitions beyond one tool”Two Cube App connector customers are named on its Private Preview roster today: Cars Commerce and Patagonia, both running Atlan alongside a live Cube deployment. Both are coexistence patterns, Atlan governing Cube rather than replacing it, consistent with the formal partnership behind the connector; Cube’s own VP of Strategy and Alliances, Brian Bickell, has said of the relationship: “Integrating our solutions is a natural fit for our customers.” Neither account has published a detailed case study yet, so this page states the roster fact plainly rather than overstating what’s publicly known about either deployment.
The broader argument that governed context belongs alongside a semantic layer, wherever that layer is defined, shows up in how Atlan customers describe the same problem outside Cube specifically, and in the wider role metadata management plays in enterprise AI. Joe DosSantos, VP Enterprise Data & Analytics at Workday, put it this way: “Atlan captures Workday’s shared language to be leveraged by AI via its MCP server. As part of Atlan’s AI labs, we’re co-building the semantic layer that AI needs.” Andrew Reiskind, Chief Data Officer at Mastercard, framed the same need from the catalog side: “AI initiatives require more context than ever. Atlan’s metadata lakehouse is configurable, intuitive, and able to scale to hundreds of millions of assets.” Neither quote describes a Cube deployment specifically, and this page doesn’t claim otherwise; both describe the general governed-context argument this Cube-specific integration is one instance of, the same argument that shows up in AI-ready data lineage more broadly: lineage that stops at one tool’s boundary isn’t lineage an AI initiative can actually rely on.
According to Gartner’s February 2026 Market Guide for Agentic Analytics, a Strategic Planning Assumption in that report states that by 2028, 60% of agentic analytics projects relying solely on MCP will fail due to the lack of a consistent semantic layer, worth reading carefully rather than at face value. Read straight, that could sound like an argument for buying a semantic layer like Cube and stopping there. It isn’t. The assumption is about needing a semantic layer at all, not about whether that layer’s own definitions are governed once they ship. Cube’s MCP answers what a metric means; it doesn’t answer where the number came from, who owns it, or whether it’s gone stale, and that’s the distinct failure mode a governed catalog exists to close. A separate 2026 benchmark from dbt Labs makes the same point from the accuracy side, not the governance side: grounding an LLM in an explicit semantic layer measurably improves text-to-SQL accuracy over letting the model write its own SQL from a raw schema, a general finding about semantics and agent accuracy, not a Cube-specific one, but it’s the same underlying reason a governed definition is worth protecting once it exists.
Is your metric layer actually governed?
Check whether the metrics your team defines in Cube, dbt, or elsewhere are still tracked, owned, and validated once they ship, and what an agent gets when it asks.
Take the Readiness ChecklistWhy governed access, not just agent access, is the real Cube question
Permalink to “Why governed access, not just agent access, is the real Cube question”Every semantic layer in this category now ships its own MCP server. Snowflake, dbt, AtScale, and Cube all hand an agent a metric definition on request, so “can an agent reach this metric” is no longer the interesting question; nearly every vendor already answers yes. The question this page has actually been answering is narrower and more useful: once an agent reaches a Cube metric, does it also get the metric’s ownership, its freshness, its lineage back to the warehouse, and the policy context around it, or just the number and a name. It’s the same question raised when OpenAI’s own Frontier work is compared against a semantic layer: a model can be arbitrarily capable and still answer confidently from a metric definition nobody’s validated recently.
Atlan’s Cube App connector is the concrete answer for Cube specifically. It doesn’t compete with Cube for the job of defining and serving metrics, that’s Cube’s job, and Cube’s own docs, case studies, and 20,800-star open-source core show it does that job well. Atlan governs the estate Cube sits inside: cataloging cubes, views, dimensions, measures, and segments, tracing lineage back to the source tables, and making that governed context reachable by any agent through MCP, A2A, SQL, and API, not only through Cube’s own multi-API layer. That’s the same governed-context pattern behind how Databricks Genie’s own ontology work relates to Atlan’s context layer: an AI-native semantic tool handles one part of the job well, and a governed context layer sits on top of it rather than replacing it, the same lesson practitioners describe when semantic layers alone failed to hold up the way context graphs do, and the same discipline a practitioner walkthrough on building a semantic layer recommends baking in from the start rather than bolting on later. As the connector moves from Private Preview toward general availability, expect broader capability coverage, enrichment, popularity signals, run-status, but the core distinction won’t change: governed agent access, not just agent access, is what separates a metric an organization can actually trust from one it can merely retrieve.
See Atlan govern a live Cube deployment
Watch how Atlan catalogs a semantic layer like Cube's and traces lineage back to the warehouse, the same governed context running across 100+ other connectors.
Watch the Live DemoFAQs about Cube and data catalog integration
Permalink to “FAQs about Cube and data catalog integration”1. How does Cube integrate with a data catalog?
Permalink to “1. How does Cube integrate with a data catalog?”Atlan’s Cube App connector catalogs Cube’s cubes, views, dimensions, measures, and segments as first-class assets with their definitions, and traces lineage back to the warehouse tables and columns those cubes are built from. That lineage is what extends past the boundary Cube’s own Semantic Catalog stops at: ownership and freshness tracking for a metric once it leaves Cube’s own deployment.
2. Is Atlan’s Cube App connector generally available?
Permalink to “2. Is Atlan’s Cube App connector generally available?”No. The Cube App connector has been in Private Preview since 2026-08-17. Discovery and lineage are live today; Browser Extension, Self-Deployed Runtime, Enrichment, Popularity, and Run-status are not yet supported, and access requires a Private Preview request.
3. What do I need before connecting Cube to Atlan?
Permalink to “3. What do I need before connecting Cube to Atlan?”A Cube deployment, Cube Cloud or self-hosted Cube Core, reachable by Atlan, the upstream warehouse already cataloged in Atlan so lineage has something to resolve against, and granted Private Preview access for the Cube App connector.
4. What is a semantic catalog?
Permalink to “4. What is a semantic catalog?”A semantic catalog is a discovery layer built into a semantic layer itself, showing what metrics, dimensions, and joins exist and how they relate. Cube ships one natively, scoped to Cube’s own deployment. It is a different thing from an external data catalog, which can see and govern assets across many systems, not just one tool.
5. Does the Cube App connector trace lineage back to warehouse tables?
Permalink to “5. Does the Cube App connector trace lineage back to warehouse tables?”Yes. The connector resolves lineage from the literal upstream warehouse tables and columns through Cube’s cubes, views, dimensions, and measures, the specific capability that stops at Cube’s own deployment boundary in Cube’s own Semantic Catalog.
6. Does Atlan replace Cube’s own Semantic Catalog?
Permalink to “6. Does Atlan replace Cube’s own Semantic Catalog?”No. Atlan extends it rather than replacing it. Cube’s Semantic Catalog stays useful for discovery inside Cube’s own deployment; Atlan adds ownership, cross-system lineage, and governed agent delivery on top, reaching beyond what any in-layer feature can see.
7. How is Atlan’s Cube integration different from DataHub’s Cube connector?
Permalink to “7. How is Atlan’s Cube integration different from DataHub’s Cube connector?”DataHub’s Cube ingestion source catalogs cubes, views, and lineage on the catalog side. Atlan’s connector does the same discovery and lineage work, then delivers that governed context to any agent through MCP, A2A, SQL, and API, alongside everything else in the estate the agent needs.
8. What if my metric definitions live in Cube, dbt, and a warehouse-native semantic view at once?
Permalink to “8. What if my metric definitions live in Cube, dbt, and a warehouse-native semantic view at once?”Atlan catalogs and governs metric definitions regardless of which tool authored them. A metric defined in Cube, dbt, or a warehouse-native semantic view all become governed assets in the same Enterprise Data Graph, so an agent gets consistent ownership and lineage context no matter where the definition lives.
Sources
Permalink to “Sources”- Cube documentation, Cube.dev
- Cube Semantic Catalog: A Unifying Catalog Embedded in Your Universal Semantic Layer, Cube.dev (2026)
- Cube Core, cube-js/cube (GitHub)
- Atlan’s Cube App connector documentation, docs.atlan.com
- Cube | DataHub Documentation, DataHub 1.7.0
- Cube Recognized in the 2026 Gartner Market Guide for Agentic Analytics, Cube.dev (Feb 2026)
- Semantic Layer vs. Text-to-SQL: A 2026 Benchmark, dbt Labs (Apr 2026)
- Atlan Partners, atlan.com
- Atlan Context Lakehouse, atlan.com
- Cube Semantic Layer: Architecture, Adoption, and Gaps, atlan.com
