Cube

Cube is a headless semantic layer for building data applications. A semantic layer is a place to define your business metrics and dimensions — what revenue, active users, or churn actually mean in query terms — once, in code, so every downstream tool computes them the same way. Headless means Cube ships no user interface of its own for those definitions; instead it exposes them through APIs (SQL, REST, and GraphQL) that any front end can consume, whether a BI tool, a custom application, or an AI agent. Cube Core, its open-source engine, connects to SQL data sources such as cloud warehouses like Snowflake, Databricks, and BigQuery, query engines, and application databases like Postgres, and it includes a caching engine to keep API queries fast under load. A separate commercial product adds a hosted platform and a UI on top of that core.

The reason a semantic layer like Cube exists is metric consistency. In many organizations, the definition of a key metric is copied into a BI tool, re-implemented in a spreadsheet, and coded again inside an application — and inevitably they drift apart, so two dashboards report different revenue and no one trusts either. Defining the metric once in Cube and serving it everywhere through APIs makes the definition the single source of truth, so every consumer of the data agrees. Being headless is what lets it feed many different surfaces from that one definition — dashboards, embedded analytics in a product, and increasingly AI agents that query data. This is a factual description of the tool's category, not an endorsement.

Cube differs from a traditional business-intelligence tool in a way worth spelling out. A conventional BI tool bundles two things: a place to define metrics and a user interface to chart and explore them, tightly coupled inside one product. Its metric definitions tend to live inside that tool and are hard to reuse elsewhere. Cube separates those concerns. It provides the metric-definition layer without the interface — headless — and exposes the definitions through APIs so any front end can use them. So Cube is not a dashboard product you look at; it is the governed layer that sits between your data warehouse and whatever tools present the numbers, ensuring they all compute metrics identically. You still bring a BI tool or build an app for the presentation.

This is why Cube is often described as headless BI or a universal semantic layer rather than a replacement for BI. It is especially useful when the same metrics must appear in several places — an internal dashboard, an analytics feature embedded in your product, and perhaps an AI agent answering questions — because all of them can call the same definitions instead of re-implementing them. The trade-off is that Cube is developer-oriented: you define metrics in code and wire up the front ends, which is more work up front than a self-contained BI tool but pays off in consistency and reuse. Whether that trade suits a team depends on how many surfaces need the same metrics and how much they value a single source of truth. Described here factually, not as a recommendation.

Use Cube precisely: it names a specific headless semantic layer, not a generic data cube or any product that happens to be called Cube in another field. In a data-stack discussion it denotes the layer where metrics and dimensions are defined once and served to downstream tools through APIs. If you are evaluating it, the relevant questions are whether you have a metric-consistency problem worth centralizing — the same numbers computed differently across tools — and whether your team is comfortable defining metrics in code and wiring up the front ends. A semantic layer earns its keep when many surfaces need to agree on the same definitions; it is overhead if a single BI tool already serves everyone. This is educational context about the term, not advice to adopt any platform.

The failure modes are confusing Cube the semantic layer with an unrelated product of the same name, expecting it to be a ready-made dashboard when it is a headless layer you still build interfaces on, and adopting a semantic layer where there is no real consistency problem to solve, adding complexity for little gain. Another trap is treating vendor descriptions of scale or adoption as verified performance, or letting the definitions in Cube drift from how the business actually reasons about a metric, which reintroduces the very inconsistency the layer was meant to end. The discipline is to name the specific product, understand that headless means definitions without a built-in UI, keep those definitions reviewed and current, adopt a semantic layer only when metric consistency across surfaces genuinely matters, and keep description separate from recommendation.

Cube — a headless semantic layer that defines metrics once and serves them via SQL, REST, and GraphQL APIs — gives BI tools, apps, and AI agents one consistent source of truth.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where cube is a core concern: