Skip to main content
Cube and canonic both put a governed layer between consumers and a warehouse, but they are built for different jobs. Cube is a semantic layer that serves many consumers at speed. canonic is a context layer that decides how a question has to be answered and says how far the answer can be trusted.
Last verified against Cube’s public documentation in October 2026.

​
What each one is

Cube models data as cubes and views with measures, dimensions and joins, written in YAML or JavaScript. Cube Core is open source (the backend under Apache 2.0, the client under MIT) and exposes the model through SQL, REST and GraphQL APIs, with a built-in caching engine and pre-aggregations for low-latency queries. Cube documents a hosted MCP server in Cube Cloud with tools to search the data model, run queries, chat and, for permitted roles, edit the model and manage pre-aggregations. canonic is a local-first context layer. It compiles a semantic query (metric names, dimensions, filters) into SQL, applies the guardrails that belong to the data, and returns the answer with the definition used and a trust tier. It is read-only against the warehouse, has no LLM in the answer path and serves agents over MCP.

​
Where they differ

Cube and canonic make different trade-offs on the first row of that table. If a hundred dashboards hit the same metric every minute, you want what Cube is good at. If an agent asks a one-off question and a silently wrong number is the expensive failure, you want what canonic is good at.

​
Using them together

canonic has no Cube connector today, so metrics defined in a Cube data model are not imported. There are two honest ways to combine the tools:
  • Side by side. Cube keeps serving dashboards and applications. canonic serves agents from the same warehouse, with its own reviewed definitions. The risk is two definitions of one metric, so bind the canonical ones in canonic from the start and use assertions to compare their numbers with what the dashboards show.
  • One model, two consumers. Keep Cube as the place your team already maintains. Draft the canonic project from the live schema and from your dbt manifest, then review the proposals against the Cube model by hand.
If you only need a fast, cached metrics API for BI tools and people, Cube is enough. canonic starts to earn its place when an agent is the consumer.

canonic and other tools

The roles and a side-by-side table for dbt, Cube, LookML and Ossie.

Contracts and guardrails

How rules are attached to the data instead of to each metric.

​
Sources