Cube vs dbt Semantic Layer vs Contextflo

If you're evaluating semantic layers, the names you'll hear most are Cube, dbt Semantic Layer, and increasingly, Contextflo, which connects your database to Claude and provides context about your data so LLMs can accurately answer questions. They all solve the same core problem (making metrics consistent) but they come from very different design philosophies and serve different teams.

Cube

Cube is a standalone semantic layer that sits between your database and your applications. You define metrics, dimensions, and joins in YAML (or JavaScript), and Cube exposes them through REST, GraphQL, and SQL APIs. It also has a built-in caching layer that pre-aggregates data for faster queries.

The tradeoff: Cube is powerful but adds infrastructure. You're running another service, maintaining YAML definitions, and managing a caching layer. Cube is historically headless, though they're adding a native BI frontend. most teams still pair it with a separate visualization tool. For internal analytics at a startup, this is usually overkill.

dbt Semantic Layer

dbt's Semantic Layer is built on MetricFlow and integrates directly with your dbt project. You define metrics in your dbt YAML files alongside your models, and downstream tools (Hex, Mode, Tableau) can query those metrics through the dbt Cloud Semantic Layer API.

The tradeoff: Requires dbt Cloud (not dbt Core), which means a paid plan. You also need someone who understands MetricFlow's syntax and can maintain the metric definitions as your data model evolves. If you don't already have a dbt project, adopting the Semantic Layer means adopting dbt first. And like Cube, dbt Semantic Layer is just the definitions. You still need a BI tool on top to query and visualize.

Contextflo

Contextflo takes a different approach. Instead of asking you to write metric definitions in YAML, it connects to your database, reads the schema, and auto-generates table descriptions, column meanings, relationships, and metric definitions. You review and refine them. You don't write them from scratch.

These definitions are served as context to Claude (or any AI) whenever someone asks a question, ensuring consistent answers across the team without a traditional modeling project.

The tradeoff: Contextflo isn't a general-purpose semantic layer API that feeds Tableau or Looker. It's purpose-built for AI-driven analytics. If your goal is to standardize metrics across five different BI tools, Cube or dbt is the right choice. If your goal is to let your team ask questions in plain English and get reliable answers, Contextflo gets you there in 10 minutes instead of 10 weeks.

Side-by-side comparison

Which one should you pick?

Choose Cube if you're building embedded analytics for customers and need a high-performance API with caching.

Choose dbt Semantic Layer if you already run dbt Cloud and want to standardize metrics across your existing BI tools.

Choose Contextflo if you want your team to ask questions in plain English, get consistent answers, and skip the YAML entirely.

The right answer depends on your team size, your existing stack, and whether you want your semantic layer to feed dashboards or feed AI. For most startups without a data team, the fastest path to consistent metrics is the one that doesn't require you to write config files.