Cube’s own home page now frames itself as an agentic analytics platform built on a semantic layer, and that shift is real: query volume increasingly comes from AI agents and LLM tools like Claude and ChatGPT, not only BI dashboards. What Cube ships to support that is a four-part system, not a single feature.
- Data modeling defines measures, dimensions, and joins once, in YAML, JavaScript, or Python.
- Access control enforces row and column-level security at the semantic layer, not inside every downstream tool separately.
- Caching layers an in-memory cache over Cube Store, a Rust-based distributed OLAP engine, for sub-second queries.
- A multi-API layer exposes the same metric definitions over SQL, DAX, REST (JSON), GraphQL, and an MCP server built for AI agents.
| What It Is | Key Benefit | Best For | Adoption | Licensing | Core Components |
|---|---|---|---|---|---|
| An agentic analytics platform built on an open-source semantic layer between a warehouse and every tool that queries it | One metric definition served consistently to dashboards, embedded analytics, and AI agents | Teams running more than one BI tool or AI application against the same warehouse data | Cube Core: 20.9k GitHub stars and 2.1k forks, checked 2026-09-18; 12,830 members in Cube’s Slack community | MIT (Cube Client) and Apache 2.0 (Cube Backend) dual license; Cube Cloud is the managed tier | Data modeling, access control, caching, multi-API layer |
What is Cube’s semantic layer?
A semantic layer sits between raw warehouse tables and the tools that query them, translating columns and joins into named metrics, like active user or net revenue retention, that mean the same thing everywhere they get used. Cube is one implementation of that idea. Its docs introduce it as the agentic analytics platform for business intelligence and embedded analytics, built on an open-source semantic layer, and Cube ships Workbooks, Dashboards, Charts, Explore, Analytics Chat, and a Slack Agent on top of that layer while serving the same governed definitions to any external tool.
Cube Core is the open-source engine behind the product, dual-licensed under MIT for the client libraries and Apache 2.0 for the backend. Cube’s own glossary entry, updated September 14, 2026, defines a semantic layer as an independent, governed layer that sits between your data sources and the tools that consume data. The cube-js/cube repository carries 20.9k stars and 2.1k forks, checked 2026-09-18, and Cube Cloud is the managed, hosted version of the same engine for teams that don’t want to run Cube Core themselves. Cube’s own about page counts 12,830 members in its Slack community and names Maersk, Wix, Patagonia, Webflow, Intuit, Walmart, and Zscaler among its customers. Cube announced $25 million in funding in June 2024, with Databricks joining the round as a strategic partner and 645 Ventures doubling down. The four-part architecture behind all of it is what the next section breaks down piece by piece.
That distinction between the open core and the managed tier matters once you’re comparing Cube against the general semantic layer category it sits inside, or against a data catalog, which solves an adjacent but different problem: a catalog inventories what data exists, a semantic layer defines what a metric built from that data means. Cube solves that second problem well, one metric, defined once, served identically everywhere it’s queried. Whether that definition stays valid once several other tools also touch the same warehouse is a different question, and it’s the one this guide answers in the sections that follow.
How does Cube’s semantic layer work?
Cube’s architecture breaks into four parts that each do one job: data modeling defines the metric, access control decides who can see it, caching makes it fast, and the multi-API layer decides how it gets served. Looking at each piece separately explains what Cube is good at and where the seams show.
Data modeling
Cube’s data models started as a JavaScript-like domain-specific language. Cube now documents YAML data modeling as the primary path, with programmatic configuration through cube.py or cube.js and a cube_dbt Python package for teams generating cubes from a dbt project. Measures, dimensions, and joins are defined once, in whichever of those three surfaces a team prefers.
Access control
Row-level and column-level security get enforced inside Cube itself, not re-implemented separately inside every BI tool, notebook, or app that queries it. That matters once several tools query the same warehouse: security policy lives in one place instead of five slightly different ones, each capable of drifting from the others.
Caching and pre-aggregations
Cube runs a two-level cache: an in-memory layer for hot queries, and Cube Store, a Rust-based distributed OLAP engine, for materialized pre-aggregations that push most query latency under a second. That performance story is closely tied to Cube’s most common deployment target, Snowflake, where pre-aggregations absorb repeated dashboard and agent queries before they ever reach the warehouse directly.
Multi-API layer
Cube’s Core Data APIs name SQL, DAX, REST (JSON), and GraphQL, and Cube adds an MCP server built for AI agents. That MCP surface is drawing the most current attention, and it reaches further than a lookup: Cube documents 30 tools across deployments and chat, query and discovery, dashboard authoring, data-model editing, committing and publishing changes, and pre-aggregation builds. It is available on Premium and Enterprise plans to a Viewer role or higher. That gives an agent governed access to a metric definition instead of letting it write its own SQL, which is a meaningfully different failure mode than an agent getting a metric wrong because nobody defined it the same way twice.
Four parts, one job each: model it, secure it, cache it, serve it. Whether the metric they serve today is still the one the business should trust tomorrow is a question about ownership and validation, which sits in a different layer. The limitations section later in this guide covers what Cube’s own docs do and do not scope.
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-bookWhat’s the difference between Cube and a BI-tool-native semantic layer?
Cube’s own use-case page describes a semantic layer as a centralized control panel that manages data modeling and data access and sends consistent data and metrics to every BI tool, data app, and AI or LLM tool. That names the real architectural distinction: Cube’s definitions live outside any single BI tool, while a BI-tool-native semantic layer lives inside one tool and has to be redefined the moment a second tool needs the same metric.
Warehouse-native semantic views, dbt’s Semantic Layer at transformation time, and Cube at query time optimize for different points in the pipeline, and none of the three is strictly better. Teams running more than one of them tend to treat them as complements, each solving a different part of the same problem.
That framing matters for what this page is actually about. A semantic layer that lives outside the BI tool solves reuse across tools. Whether the metric being reused is the right one, and whether the same metric defined slightly differently in dbt or a warehouse-native semantic view has already drifted from it, is a separate question. This page also isn’t the place to rank every option in the category; a full head-to-head across the best semantic layer tools already covers that ground.
| Aspect | BI-tool-native (e.g., LookML in Looker) | Cube |
|---|---|---|
| Where metrics live | Inside the BI tool’s own modeling layer | In Cube, independent of any single BI tool |
| Consumption surface | That one BI tool’s dashboards and explores | SQL, DAX, REST (JSON), GraphQL, and MCP, so any tool can query the same metric |
| Reuse across tools | Requires redefining the metric in each new tool | Define once, serve to every connected tool |
| Documented governance scope | The BI tool’s own permissions model | Row- and column-level security, security contexts, and access policies at query time |
| Performance approach | Depends on the BI tool’s own caching, if any | Two-level cache plus Cube Store pre-aggregations |
When does a Cube semantic layer make sense?
Cube’s use-case page names two jobs it is built for: embedded analytics, and LLM and AI grounding. A third pattern, metric consistency across tools, runs through its case studies. Each has real, credited results behind it.
Embedded analytics and dashboard performance
SecurityScorecard moved off Sisense onto Cube. Its engineering manager credits pre-aggregations with reducing requests to Snowflake by 2x; its VP of engineering credits the swap from Sisense itself with cutting total infrastructure cost 60%. Two numbers, two causes, and the case study keeps them apart. Cloud Academy saw a comparable shift: Alessandro Lollo, Senior Data Engineer at Cloud Academy, said, “With Cube, we’ve been able to speed up time to release a new data model to production by 5x and decrease analytics downtime by 90%.”
AI-agent and LLM grounding
That governed-access argument from the previous section has a concrete voice in Cube’s own case studies. Dan Meshkov, Staff Software Engineer at Brex, put it this way: “The LLM is the engine, but the semantic layer is the map.” The stakes behind that framing are measurable. According to Rumiantsau and Fokeev (arXiv:2604.25149, 2026), adding a hand-authored semantic-context document lifted text-to-SQL accuracy 17 to 23 percentage points across three frontier LLMs, converging Claude Opus, Claude Sonnet, and GPT to statistically indistinguishable accuracy against a schema-only baseline. That isn’t a Cube-specific finding, but Cube’s MCP server is one concrete way a team operationalizes it, and it’s the same argument behind RAG accuracy problems and semantic layers for AI agents generally. It’s also why what RAG actually retrieves and how an agent’s memory architecture decides what gets remembered between calls both depend on the same underlying question: whose metric definition is the agent actually grounding against.
Multi-tool metric consistency
Anthony Cronander, Senior Analytics Engineer at Drata, described the pattern directly: “Cube becomes our single source of truth for metric definitions and powers everything from customer-facing dashboards to AI-driven quarterly business reviews.” That’s the use case Cube is built for: one definition, many consumers. It’s a related but separate question from how an agent stores what it learns between calls, whether that’s semantic memory or procedural memory, or the ongoing architecture choice between a vector database and a knowledge graph for holding that memory; Cube’s own case studies don’t speak to that layer at all. What Drata’s quote does speak to directly is the exact use case where the next section’s limitation starts to matter, because “single source of truth” is a claim about a metric’s definition, not about whether that definition is still the one everyone downstream should trust.
Is your metric layer actually governed?
Run a quick assessment to see whether the metrics your team defines in Cube, dbt, or elsewhere are still tracked, owned, and validated once they ship.
Take the AssessmentWhat are Cube’s real limitations?
This section covers the boundaries Cube’s own documentation draws, not a knock on the product. Every semantic layer draws them somewhere; Cube’s are worth naming plainly.
Several capabilities are plan-gated, and that is the first thing to check against a rollout plan. Cube documents the MCP server on Premium and Enterprise only, and the dbt integration’s pull direction on Premium and above, with dbt push still in preview. Hierarchies and flat folders are supported in Cube for Excel, Cube for Sheets, and Playground, and not across every consumption surface.
Cube Core’s open-source license means self-hosting is genuinely available, with a documented production architecture of API instances, refresh workers, and Cube Store. It also means someone on the team owns the operational overhead: uptime, scaling Cube Store, and version upgrades. Cube Cloud exists specifically to remove that overhead for a managed-service fee, which is the tradeoff to evaluate rather than a limitation to avoid outright.
The boundary that matters most for this page’s purpose is one of scope. Cube’s docs cover what a metric means, how it is calculated, and who may query it. Who owns that definition, when it was last validated, and what breaks downstream if someone changes it live in a different layer. That question starts to matter the moment more than one semantic layer exists inside the same company, which for most enterprises running dbt, Snowflake, and a BI tool alongside Cube is already the default state, not an edge case. Teams that have run into this from the other direction describe the same gap in semantic layers that failed to hold up the way context graphs do, and in the wider debate over where a context graph differs from an ontology in how each handles this exact accountability question. The same distinction shows up in how ontology and semantic layer get compared directly, in a plain-language ontology explainer for teams new to the term, and in how a data catalog differs from a context layer when it comes to who is actually accountable for a definition once it ships.
| Signal | Cube likely fits | Look elsewhere or add a layer |
|---|---|---|
| Multiple tools query the same warehouse | Yes, one definition instead of five | Not applicable |
| Team wants a fully managed service | Cube Cloud covers this | Self-hosting Cube Core adds real operational overhead |
| Need row or column security enforced once | Yes, built into the access-control layer | Not applicable |
| Need an MCP surface for agents | Yes, 30 documented tools | Premium and Enterprise plans only, Viewer role or higher |
| Need ownership, certification, and cross-tool lineage on a metric | Outside the scope Cube’s docs cover | Evaluate a separate governance or context layer |
| Need hierarchies and flat folders everywhere | Documented for Cube for Excel, Cube for Sheets, and Playground | Check the consumption surface you actually use |
How Atlan approaches semantic layer governance
Cube's semantic layer answers what a metric means; the context layer above it answers whether you can trust the metric and who owns it. Source: Atlan.
Everything above answers what a metric means and how Cube calculates it, and Cube does that job well. Who owns a given definition, whether it’s still valid, and what breaks downstream if it changes are a second job, and it is not a job specific to Cube. The market already splits along that line: one camp defines metrics once, tools like dbt, Snowflake, and Cube; a separate camp wraps governance, lineage, and validation around whatever’s already been defined, no matter which tool defined it.
Atlan is the Context Layer for AI. Its context layer carries live lineage, ownership, and validation status alongside a metric definition, wherever that definition was authored, in Cube, dbt, or a warehouse-native semantic view, so an agent or analyst gets the same governed context regardless of which tool wrote the metric. In practice, that means Atlan ingests semantic-layer definitions from tools like Cube, dbt, and LookML as first-class assets, with lineage traced back to the warehouse tables underneath them, so the context layer and the semantic layer stay connected instead of drifting apart the moment either one changes. That’s the same distinction covered in how active metadata compares to a full context layer, and in how context agents access live metric context rather than a stored extract that ages the moment it’s taken.
The accuracy math from earlier in this guide is the reason that connection is worth building deliberately rather than assuming it happens on its own: a well-modeled semantic layer already lifts text-to-SQL accuracy by double digits. What that accuracy is worth downstream depends on whether the definition behind it is one every tool in the stack still agrees on, which is exactly what an enterprise context layer exists to verify, and what a context graph makes queryable once that verification is in place. The same discipline applies once agents, not dashboards, are the primary consumer: context graphs built for AI agents, the broader practice of context engineering and its application to AI agents specifically, and why MCP matters for AI agents beyond Cube’s own server all depend on the same governed definition holding steady underneath them, the same way an MCP-connected data catalog ties governed access back to a single source.
See how Atlan governs metrics wherever they're defined
Watch a live walkthrough of how Atlan's context layer tracks ownership, lineage, and validation status for metrics defined in Cube, dbt, and beyond.
Watch the Live DemoFAQs about Cube’s semantic layer
1. What is a semantic layer, with an example?
A semantic layer is a translation layer that maps raw database columns and joins into named business metrics, like monthly active users or net revenue retention, so every tool querying the warehouse gets the same definition. For example, instead of five dashboards each calculating “active user” with slightly different SQL, the semantic layer defines it once and every dashboard reads that single definition.
2. What’s the difference between a cube and a semantic model?
A cube, in Cube’s own terminology, is the specific modeling unit: a defined set of measures and dimensions built from one or more tables. A semantic model is the broader concept, the full set of metric and dimension definitions across an organization’s data. Cube’s product name comes from that modeling unit, not the other way around.
3. Is Cube Core open source?
Yes. Cube Core is open source and dual-licensed: the client libraries under MIT and the backend under Apache 2.0. The repository lives at cube-js/cube on GitHub, which is where the older Cube.js name survives. Cube Cloud is a separate, managed, commercial tier built on the same open-source core for teams that don’t want to operate Cube Core themselves.
4. How does Cube’s caching work?
Cube uses a two-level cache: an in-memory cache for frequently run queries, and Cube Store, a Rust-based distributed OLAP engine, for materialized pre-aggregations. Pre-aggregations precompute and store query results ahead of time, which is what pushes most dashboard and API query latency under a second.
5. Does Cube render its own dashboards?
Yes. Cube documents Workbooks, Dashboards, Charts, Explore, Analytics Chat, and a Slack Agent alongside the semantic layer, and it serves the same definitions over APIs to any external BI tool. Cube uses the word headless in its docs for the embedding path, the core APIs an application calls, rather than as the name of its category.
6. Can Cube connect to Power BI and other BI tools?
Yes. Cube’s Core Data APIs expose the same metric definitions over SQL, DAX, REST (JSON), and GraphQL. Power BI connects over DAX, and Cube ships named Cube for Excel and Cube for Sheets connectors for spreadsheet users. Cube’s own positioning line is that a semantic layer sends consistent data and metrics to every BI tool, data app, and AI or LLM tool.
7. What is Cube Cloud, and how is it different from Cube Core?
Cube Core is the open-source engine a team can self-host. Cube Cloud is Cube’s managed, commercial version of that same engine, run and scaled by Cube instead of an internal infrastructure team. Modeling and the API layer work the same way in both; the difference is who operates the deployment.
8. What governance does Cube document?
Cube documents row-level and column-level security, security contexts, and access policies enforced inside the semantic layer at query time. Ownership of a definition, its validation status, and lineage across every other tool that defines the same metric are a separate layer, and teams add a governance or context layer on top of Cube for that.
Sources
- What Is a Semantic Layer?, Cube.dev (Sep 14, 2026)
- Cube Core, cube-js/cube (GitHub)
- Introduction, Cube Documentation
- Core Data APIs, Cube Documentation
- MCP Server, Cube Documentation
- Semantic Layer use case, Cube.dev
- Cloud Academy case study, Cube.dev
- Drata case study, Cube.dev
- SecurityScorecard case study, Cube.dev
- Brex case study, Cube.dev
- Semantic Layers for Reliable LLM-Powered Data Analytics, arXiv:2604.25149 (Rumiantsau and Fokeev, Apr 28, 2026)
- Pre-Aggregations, Cube Documentation
- About Cube, Cube.dev
