Cube vs dbt Semantic Layer vs Contextflo: I Tried All Three

All three solve the same stated problem: making sure that revenue means the same thing no matter who asks. They disagree completely on who should be doing the defining, and that is the decision you are actually making.

Cube and dbt both assume you have someone who will write and maintain metric definitions. Contextflo assumes you do not, which describes most companies: it generates the definitions from your schema, code and docs, and sharpens them as your team saves corrections.

Cube

Cube is a standalone semantic layer between your database and your applications. You define metrics, dimensions and joins in YAML or JavaScript, and Cube serves them over REST, GraphQL and SQL APIs. It also has a caching layer that pre-aggregates data, which is the reason a lot of teams pick it.

Best for:

• Customer-facing analytics, where you are embedding dashboards in your own product
• High-concurrency workloads where pre-aggregation is doing real work
• Teams with engineers who will own the data model

The tradeoff. Cube is infrastructure. You are running a service, maintaining definitions, and managing a cache with its own invalidation behaviour. It is historically headless. They are building out a native BI frontend, but most teams still pair it with a separate visualisation tool.

The caching is the genuine differentiator here, and it is also the tell for whether Cube is right for you. If you are serving the same aggregate to thousands of users a minute, pre-aggregation is worth the operational cost. For internal analytics at a company of forty people, you are running a caching layer to make queries fast that were never slow.

dbt Semantic Layer

Built on MetricFlow, it lives inside your dbt project. Metrics are defined in YAML alongside your models, and downstream tools like Hex, Mode and Tableau query them through the dbt Cloud Semantic Layer API.

Best for:

• Teams already running dbt Cloud as their transformation layer
• Organisations with analytics engineers who own the dbt project
• Companies standardising metrics across several BI tools at once

The tradeoff. It requires dbt Cloud, not dbt Core, so there is a paid plan involved. You also need someone fluent in MetricFlow's syntax who will keep definitions current as the data model moves. And if you are not already on dbt, adopting the Semantic Layer means adopting dbt first, which is a much larger project than the one you thought you were starting.

Like Cube, it is definitions only. You still need a tool on top to query and visualise.

The honest case for dbt here is narrow and strong: if the dbt project already exists and is well maintained, defining metrics next to the models that produce them is the most coherent place to put them. That is a real advantage, and no amount of auto-generation replicates it.

Contextflo

Different starting assumption. Rather than asking you to write definitions, Contextflo connects to your database, reads the schema and any source code or docs you point it at, and generates table descriptions, column meanings, relationships and metric definitions. You review and correct them.

Those definitions are then served as context to Claude, or any AI tool, whenever someone asks a question. The consistency comes from every question resolving against the same definitions, rather than each person's phrasing.

Best for:

• Teams that want dashboards and consistent metrics without standing up and maintaining a separate modelling layer
• Companies using AI as the primary way people ask data questions
• Getting to consistent metrics without a multi-week modelling project

The tradeoff. It is not a general-purpose semantic layer API. It does not feed Tableau or Looker. If the goal is standardising metrics across five BI tools, Cube or dbt is the right answer and this is not close.

The second tradeoff is more important and gets glossed over in comparisons like this one: generated definitions are a draft. They are usually right about structure and frequently wrong about business meaning, because no schema records that orders from before the 2024 migration have a different status vocabulary. Somebody who knows the business still has to read them. What changes is that reviewing a draft is a couple of hours, and writing definitions from an empty file is a couple of weeks.

Side by side

The "caching: none" row is deliberate rather than a gap. Every query hits your warehouse live, so nothing is stale and nothing is stored on our side, and you pay your warehouse for the compute you use.

What continuous agent querying costs

A semantic layer priced per query or per metric call was designed for a world where a dashboard loads a handful of tiles and a person reads them. Point an AI agent at that same API and the shape of usage changes. Two-thirds of the questions in our logs are follow-ups, and a single session once ran past seventy. Each of those is another metered call.

dbt's Semantic Layer bills through dbt Cloud on a consumption model that counts the metrics you query, and Cube's managed cloud scales with usage as well. Neither is doing anything strange; that is how a metered API is meant to work. It does mean that the more your team leans on an agent to keep asking, the more each conversation costs, and the pricing quietly works against the exact behaviour you were hoping to encourage.

Contextflo does not meter per query. It is $75 per user per month, and someone can ask two questions or two hundred in a session for the same price. Your warehouse still bills you for the compute each query uses; Contextflo does not add a toll on top of that.

Which problem do you have?

Choose Cube if you are building analytics into a product your customers use, and concurrency and latency are real constraints.

Choose dbt Semantic Layer if you already run dbt Cloud, have an analytics engineer, and want several BI tools agreeing on the same numbers.

Choose Contextflo if the bottleneck is that people cannot get answers without asking someone, and nobody on your team is going to write and maintain YAML for the next two years.

That last one is worth being blunt about, because the failure mode is common: teams buy a semantic layer, define nine metrics in the first month, and then the person who owned it moves on. The definitions drift, people stop trusting them, and everyone quietly goes back to asking the data team. A semantic layer is only as good as its maintenance, so the honest question is not which tool is most capable but which one your team will still be keeping current a year from now.

Here is a more in-depth look at Contextflo and how it works.