Cube D3 vs Mitzu: Agentic BI, Governed Metrics and the Semantic Layer Compared

Use this comparison if you are choosing a semantic layer with AI agents for governed metrics and self-service BI: how Cube D3 and Mitzu define metrics, who writes the SQL, and what each runs on the same definitions.

Cube calls itself "the agentic analytics platform built on a semantic layer," and was named in the 2026 Gartner Market Guide for Agentic Analytics. Cube D3 is their agentic product, layering AI agents on top of the universal semantic layer that already powers BI, embedded analytics and dashboards. Mitzu competes for the same job, governed metrics and self-service BI on the warehouse with AI agents on top, and runs product analytics and experiment analysis on the same definitions, with a deterministic query engine that owns the SQL. Both are warehouse-native. They differ in how the semantic layer is built, who writes the SQL, and which consumers each serves.

What is Cube D3?

Cube started as an open-source semantic layer (cube-js/cube) and grew into a commercial platform, Cube Cloud, covering BI, embedded analytics, and now agentic analytics under the D3 banner. The product page positions Cube as "Universal Semantic Layer. Business Intelligence. Embedded Analytics."

Cube D3 ("data in cube") was announced in June 2025 and ships three AI agents on top of the semantic layer:

• Semantic Model Agent: proposes and edits cubes, views, measures and dimensions; helps build the semantic layer from scratch or extend an existing one.
• Workbook Agent: assembles reports and visualizations inside the Workbooks surface, with point-and-click, SQL, and Python paths alongside the AI flow.
• Analytics Chat Agent: answers business questions in natural language, running multiple queries against the semantic layer and summarizing the result.

The platform exposes its agents via MCP (available in Claude Desktop) and A2A so external agents (Claude, ChatGPT, custom) can call into Cube the way they would any tool. Data access is standardized on REST, GraphQL and SQL. See Cube's MCP write-up for the protocol details. Cube's site now also lists a Dashboard Agent that builds dashboards conversationally and a Slack agent that answers in-thread.

Underneath, the semantic layer is the same one Cube has shipped for years. Data models are authored in YAML, JavaScript or Python. Cubes represent business entities; views compose cubes into the surfaces consumers actually query; measures, dimensions, segments, joins and pre-aggregations live inside cubes. It is a BI-shaped model, strong for descriptive analytics, embedded dashboards and metric APIs, and the model is hand-authored upfront, then maintained as the warehouse evolves.

What is Mitzu?

Mitzu is an analytics platform on your data warehouse for BI, product analytics and experiment analysis, where the data team governs the metrics and everyone uses them through dashboards, an AI agent, Slack and their own AI assistants. Like Cube D3, it covers governed metrics and self-service BI with agents on top. Unlike Cube, it does not feed other BI tools or embedded customer-facing analytics; instead the same definitions also run funnels, retention, journeys and A/B test analysis inside Mitzu.

The data team defines metrics such as net revenue, orders, average order value and margin once, on its own fact and dimension tables, and Mitzu can draft those definitions from the warehouse and dbt models for the data team to review. A Configuration Agent scans the warehouse for event and dimension tables, identifiers and property values. Every KPI dashboard, agent answer and scheduled agent reuses the same definitions, and each person sees only the data their Mitzu role allows. People reach Mitzu in the app, by mentioning @mitzu in Slack, through a remote MCP server from Claude, ChatGPT, Cursor, GitHub Copilot and other MCP clients, and through emails from scheduled monitoring agents that review dashboards and KPIs. Supported warehouses include Snowflake, BigQuery, Databricks, Redshift, ClickHouse, PostgreSQL, Athena, Trino, Firebolt and Microsoft Fabric.

The trust differentiator: Mitzu's agent does not write SQL. It assembles structured analysis specifications (a metric and its breakdown, funnel steps with a conversion window, retention cohorts and return events, segmentation filters with sampled property values, journey definitions, an experiment and its metrics) and a deterministic query engine turns those specifications into SQL. The same specification produces the same SQL every time. Methodology errors that LLMs reliably make, such as a funnel without a window, a retention chart that double-counts or a cohort defined wrong, are prevented by the engine rather than by prompt engineering.

Cube D3 vs Mitzu: side-by-side

SQL examples: a funnel, two architectures

A governed KPI question such as "What was net revenue last quarter?" works in both tools once the measure or metric is defined. The difference shows on the product question that usually comes next: "What is our 7-day signup-to-activation conversion rate, broken down by acquisition channel, for the last 30 days?"

Cube D3: a semantic model and an LLM-authored query

In Cube you'd model the underlying events as a cube, then expose a view the agents can reach. A minimal model in YAML:

# model/cubes/events.yml — hand-authored
cubes:
  - name: events
    sql_table: analytics.events
    dimensions:
      - name: user_id
        sql: user_id
        type: string
      - name: event_name
        sql: event_name
        type: string
      - name: channel
        sql: "{CUBE}.properties:channel::text"
        type: string
      - name: event_time
        sql: event_time
        type: time
    measures:
      - name: count
        type: count
      - name: distinct_users
        sql: user_id
        type: count_distinct

views:
  - name: activity
    cubes:
      - join_path: events
        includes: "*"

With the model in place, the Analytics Chat agent grounds an LLM query against the view. A plausible LLM output for the funnel question:

-- Plausible LLM output against the Cube view.
-- Methodology depends on the prompt, the grounding, and the day.
WITH signups AS (
  SELECT user_id,
         min(event_time) AS signup_at,
         any_value(channel) AS channel
  FROM activity
  WHERE event_name = 'signup'
    AND event_time >= now() - interval '30 days'
  GROUP BY user_id
),
activations AS (
  SELECT user_id, min(event_time) AS activated_at
  FROM activity
  WHERE event_name = 'activated'
    AND event_time >= now() - interval '37 days'
  GROUP BY user_id
)
SELECT s.channel,
       count(*) AS signups,
       count(*) FILTER (WHERE a.activated_at <= s.signup_at + interval '7 days') AS activated_in_7d,
       round(100.0 * count(*) FILTER (WHERE a.activated_at <= s.signup_at + interval '7 days')
             / nullif(count(*), 0), 1) AS conv_pct
FROM signups s
LEFT JOIN activations a USING (user_id)
GROUP BY s.channel
ORDER BY signups DESC;

The semantic layer keeps the join graph and column names consistent. The conversion window, the anchor row for channel attribution, and the distinct-user logic are still authored by the LLM in the prompt. A different prompt, or a slightly different schema, can return: a window measured against the wrong anchor, an activation that pre-dates the signup counted as a conversion, or channel attribution joined off the wrong row when a user has multiple signups. None of these are SQL bugs.

They are methodology choices an LLM is making implicitly, every time.

Mitzu: SQL from a deterministic engine

The Mitzu agent does not write the SQL. It assembles a funnel specification, roughly { first_event: "signup", subsequent_events: ["activated"], conversion_window: "7d", breakdown: "channel", date_range: "last_30_days" }, and the deterministic engine emits the same SQL every time:

-- Engine output for a 2-step funnel with a 7-day conversion window,
-- broken down by channel, for the last 30 days. Same spec → same SQL.
WITH step_1 AS (
  SELECT user_id,
         min(event_time)             AS step_1_at,
         any_value(channel)          AS channel
  FROM events
  WHERE event_name = 'signup'
    AND event_time >= now() - interval '30 days'
    AND event_time <  now()
  GROUP BY user_id
),
step_2 AS (
  SELECT s1.user_id,
         s1.channel,
         min(e.event_time) AS step_2_at
  FROM step_1 s1
  INNER JOIN events e
    ON e.user_id = s1.user_id
   AND e.event_name = 'activated'
   AND e.event_time >  s1.step_1_at
   AND e.event_time <= s1.step_1_at + interval '7 days'
  GROUP BY s1.user_id, s1.channel
)
SELECT s1.channel                                AS channel,
       count(DISTINCT s1.user_id)                AS step_1_users,
       count(DISTINCT s2.user_id)                AS step_2_users,
       round(100.0 * count(DISTINCT s2.user_id)
             / nullif(count(DISTINCT s1.user_id), 0), 1) AS conv_pct
FROM step_1 s1
LEFT JOIN step_2 s2 USING (user_id)
GROUP BY channel
ORDER BY step_1_users DESC;

The conversion window is enforced strictly (activation must be after signup and within 7 days). Distinct users prevent double-counting. Channel comes from the signup row, so attribution is consistent. The engine has been generating this shape of SQL in production for years; the agent's job is to assemble the specification, not to author the query.

The SQL is shown to the analyst as a verification artifact, not as the agent's authored work, and the funnel can sit on the same dashboard as the revenue KPI it explains.

UI surfaces — where the work happens

Cube D3 centers on a workspace UI where the Semantic Model Agent and an analyst co-author cubes, views and metrics; Workbooks combine point-and-click, SQL, Python and AI flows for analyst-led report building; Analytics Chat is the natural-language entry point for business users. The same semantic layer also feeds BI tools (Tableau, Power BI, Looker), spreadsheets (Excel, Google Sheets), embedded analytics, and external agents over MCP.

Mitzu keeps the work inside one workspace and brings the agent to the tools people already use. Inside the app, KPI dashboards, point-and-click insights (funnels, retention, segmentation, journeys), experiment results and the analytics agent share the same semantic layer and the same engine, and any chart the agent builds can go straight onto a shared dashboard. In Slack, the Mitzu agent (@mitzu) reads thread context and answers in the thread, so people get answers without opening the app. The remote MCP server gives Claude, ChatGPT, Cursor and GitHub Copilot the same governed answers, and scheduled monitoring agents review dashboards and email the team when something moves. See the BI page and the product analytics page for screenshots of the in-app surfaces.

Advantages and trade-offs

Cube D3

Mitzu

Capability scorecard

Where each tool stands on governed metrics and BI, on product analytics and experiment analysis, and on how people reach the agents.

When to choose Cube D3, Mitzu, or both?

For governed metrics, dashboards and an agent that answers from them, the two overlap. Cube D3 is a universal semantic layer with an agentic layer on top, strong when many consumers, including other BI tools and embedded analytics, share one model. Mitzu is one analytics platform where the same governed definitions run KPI dashboards, product analytics and experiment analysis, with a deterministic engine that keeps the methodology right. The right choice depends on who consumes the metrics and which questions dominate the team's workload.

• Choose Cube D3 when you need one semantic layer feeding BI tools, spreadsheets, embedded analytics and AI agents from a single model, and you have the engineering cycles to author and maintain that model in YAML, JavaScript or Python.
• Choose Mitzu when you want KPI dashboards plus funnels, retention, journeys and A/B test results on one set of definitions the data team governs; an agent that explains why a number moved (why did week-2 retention drop, did the new pricing page move trial-to-paid) with SQL from a deterministic engine; and the same answers in Slack, AI assistants and scheduled monitoring emails.
• Run both when Cube already serves embedded analytics or feeds Tableau, Power BI or Looker, and internal teams want Mitzu for KPI dashboards, product analytics and experiment analysis on the same warehouse. External agents can reach both via MCP.

FAQ

Can Cube D3 replace a product analytics tool?

For descriptive product metrics (DAU, weekly events by feature, signups by channel), Cube D3 will answer well, especially once the underlying cubes are modeled. For diagnostic product analytics (funnels with strict conversion windows, retention cohorts, journey trees, churn analysis, sampled filter values, impact analysis on a release), methodology lives in whatever SQL the LLM authors against the semantic layer. A deterministic engine that owns the methodology removes a class of error that a BI-shaped semantic layer alone cannot. In Mitzu, those analyses sit next to the KPI dashboards and experiment results, on the same definitions.

Does Mitzu have a universal semantic layer like Cube?

Mitzu's semantic layer is governed and shared across everything inside Mitzu, but it is not universal in Cube's sense. It holds metrics such as net revenue, orders and margin on fact and dimension tables, plus events, event properties, entities (users, accounts, teams), dimension properties and sampled property values, and every Mitzu dashboard, agent answer, Slack reply, MCP answer and monitoring agent uses it. It does not serve other BI tools or embedded customer-facing analytics. If those are the workloads, a universal semantic layer like Cube is the right shape.

Is Cube open source? Is Mitzu open source?

Cube has an open-source core (cube-js/cube) plus a commercial Cube Cloud where Cube D3 lives. Mitzu is a commercial SaaS product; the Enterprise plan supports self-hosted deployment in the customer's own infrastructure. Every plan has unlimited events and no per-event pricing; see the pricing page for current details.

Can I use Cube D3 and Mitzu together?

Yes. Both expose MCP endpoints. A team using Cube to feed embedded analytics or other BI tools can run Mitzu in parallel for internal KPI dashboards, product analytics and experiment analysis, with both reading from the same warehouse. The cost is two sets of definitions to keep in sync.

An external agent (Claude, Cursor, ChatGPT, custom) can be wired to call either backend.

Where does the data live in either tool?

In the customer's warehouse. Cube reads the warehouse through its semantic layer; Mitzu reads the warehouse through its deterministic engine. Neither moves data into a vendor silo. Compliance, data residency and cost control stay on the customer's side of the line.

Related reading

• ClickHouse AI vs Mitzu
• Agentic Analytics Platforms Compared
• The Semantic Layer for Agentic Analytics
• ChatGPT vs AI Analytics Agent
• How AI Agents Query Your Data Warehouse
• Mitzu BI and Warehouse Metrics
• Mitzu Experiment Analysis
• Mitzu Semantic Layer
• Mitzu Product Analytics

References

• Cube: agentic analytics platform
• Cube blog: Announcing Cube D3
• Cube blog: Cube agentic analytics
• Cube blog: 2026 Gartner Market Guide for Agentic Analytics
• Cube blog: MCP for universal data access
• Cube documentation: Data modeling syntax
• cube-js/cube on GitHub
• Mitzu documentation (docs.mitzu.io)