ClickHouse AI vs Mitzu: Agentic SQL on the Warehouse vs Agentic Product Analytics on the Warehouse

Use this comparison to evaluate tools through an agentic analytics lens: which platform enables an AI data analyst workflow with trusted SQL and a trusted semantic layer, not just faster dashboarding.

ClickHouse has been calling itself an AI-first data warehouse, anchored by the Agentic Data Stack at clickhouse.com/ai and the AgentHouse demo. That makes "ClickHouse AI vs Mitzu" a fair question to ask: both run on the warehouse, both promise an agentic analytics workflow, and ClickHouse-using teams sit squarely in Mitzu's ICP. The honest framing is that they sit at different layers. ClickHouse AI is general-purpose agentic SQL on the warehouse. Mitzu is agentic product analytics on the warehouse — narrower category, deterministic engine, semantic layer specialised for funnels, retention, journeys and cohorts. They are complementary, and Mitzu connects to ClickHouse as a first-class warehouse.

What is ClickHouse AI?

ClickHouse AI is the umbrella name for ClickHouse's agentic offering. The public product page positions it as an "Agentic Data Stack" and an "Agent-native data stack" — open-source pieces composed together: ClickHouse for storage and query, LibreChat for the chat interface, Langfuse for traces and evaluation, and MCP for tool integrations. AgentHouse is the live demo of the stack.

The clearest reference implementation is DWAINE — ClickHouse's internal "Data Warehouse AI Natural Expert," documented on their company blog. Claude (via AWS Bedrock) writes SQL against ClickHouse, grounded by three MCP servers — ClickHouse itself, a GitHub-hosted business glossary and dbt docs, and a filesystem-based column dictionary. The blog post reports 250+ internal users, "self-correcting query errors based on database feedback," and that the tool "enables non-technical users… to get immediate answers to business questions without writing a single line of SQL." Roughly 70% of the historic SQL workload moved into chat; 30% remains in Superset for certified financials and operational dashboards.

• No-code agents — build and share specialised agents across the team, from chat.
• Charts and dashboards from chat — visualisations are LLM-generated, not assembled from a typed methodology layer.
• MCP-extensible — connect to any tool that speaks Model Context Protocol; Shopify is cited running 30+ internal MCP servers.
• Langfuse observability — traces every agent workflow, scores outputs, monitors quality, cost and latency per LLM call.
• Open-source stack — every component is open source, deployable in your own infrastructure.

The architecture is general-purpose by design. The use cases on the public page span cancer genomics (cBioPortal), enterprise knowledge discovery (Shopify), product activation (Fetch / FAST) and employee-facing AI (Daimler Truck). It is not pitched specifically at product analytics, and the stack does not ship native funnel, retention, segmentation or cohort primitives. Methodology lives in whatever SQL the LLM produces.

What is Mitzu?

Mitzu is an agentic product analytics platform that runs on your data warehouse and answers behavioural questions through natural-language conversation, without writing SQL. The category is narrower than general agentic analytics — Mitzu is specialised for product, growth and marketing behavioural questions on event data.

Mitzu meets users in three places: the in-app Analytics Agent, the Slack Agent in any public or private channel, and a remote MCP server that exposes Mitzu's capabilities to any MCP-compatible agent (Claude, Cursor, ChatGPT, custom). Setup is handled by a Configuration Agent that scans the warehouse, recognises common event schemas (Segment, Snowplow, Firebase, GA4, custom), maps user and group identifiers, and builds the semantic layer automatically. ClickHouse is one of the supported warehouses — see Product Analytics with ClickHouse and Mitzu.

The trust differentiator: Mitzu's agent does not write SQL. It assembles structured analysis specifications — funnel steps with a conversion window, retention cohorts and return events, segmentation filters with sampled property values, journey definitions — 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 (a funnel without a window, a retention chart that double-counts, a cohort defined wrong) are guard-railed by the engine, not by prompt engineering.

ClickHouse AI vs Mitzu: side-by-side

SQL examples: the same question, two paths

Take a typical product analytics question: "What is our 7-day signup-to-activation conversion rate, broken down by acquisition channel, for the last 30 days?"

ClickHouse AI: SQL the LLM might generate

-- Plausible LLM output against a ClickHouse events table.
-- Looks reasonable; methodology depends on the prompt + grounding.
WITH signups AS (
  SELECT user_id,
         min(event_time)              AS signup_at,
         any(properties['channel'])   AS channel
  FROM events
  WHERE event_name = 'signup'
    AND event_time >= now() - INTERVAL 30 DAY
  GROUP BY user_id
),
activations AS (
  SELECT user_id, min(event_time) AS activated_at
  FROM events
  WHERE event_name = 'activated'
    AND event_time >= now() - INTERVAL 37 DAY
  GROUP BY user_id
)
SELECT s.channel,
       count()                                                       AS signups,
       countIf(a.activated_at <= s.signup_at + INTERVAL 7 DAY)       AS activated_in_7d,
       round(activated_in_7d / signups * 100, 1)                     AS conv_pct
FROM signups s
LEFT JOIN activations a USING (user_id)
GROUP BY s.channel
ORDER BY signups DESC;

Reads cleanly, but the methodology is doing a lot of work in the prompt. A different prompt run, or a slightly different schema, can yield: a window measured against the wrong anchor, an activation that pre-dates the signup counted as a conversion, channel attribution joined off the wrong row when a user has multiple signups, or a window that quietly slips to 30 days because the LLM conflated the lookback with the conversion window. 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(properties['channel'])  AS channel
  FROM events
  WHERE event_name = 'signup'
    AND event_time >= now() - INTERVAL 30 DAY
    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 DAY
  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(count(DISTINCT s2.user_id)
             / nullIf(count(DISTINCT s1.user_id), 0) * 100, 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 the agent's authored work.

Advantages and trade-offs

ClickHouse AI

Mitzu

Capability scorecard

Where each tool stands on the capabilities that matter for product analytics work.

When to choose ClickHouse AI, Mitzu, or both?

These are layers, not substitutes. The ClickHouse AI stack gives you a general agentic interface to the warehouse. Mitzu gives you a product-analytics-specialised agent on top of the same warehouse. The right choice depends on what shape of question dominates your team's analytics workload.

• Choose ClickHouse AI when your analytics surface is broad and cross-domain, you want full control of an open-source stack, and you have the engineering cycles to assemble and maintain LibreChat + Langfuse + MCP servers + grounding docs.
• Choose Mitzu when product, growth or marketing teams need to ask diagnostic behavioural questions (why did week-2 retention drop, did the new pricing page move trial-to-paid, which onboarding step has the highest drop-off) and you want methodology guard-rails the LLM cannot break.
• Run both when ClickHouse is the system of record for a wide analytics surface and product analytics is one of several question types — let ClickHouse AI handle the long tail and let Mitzu specialise in the behavioural layer.

FAQ

Does Mitzu work with ClickHouse?

Yes. ClickHouse is a first-class supported warehouse. Mitzu reads event tables and dbt-modelled tables in place — no data movement, no per-event pricing. See Product Analytics with ClickHouse and Mitzu for a walk-through, and Top 5 Product Analytics tools for ClickHouse for the broader landscape.

Does ClickHouse AI replace Mixpanel, Amplitude or other product analytics tools?

Not by itself. ClickHouse AI is general-purpose agentic analytics on warehouse data. For product analytics methodology specifically — funnels with conversion windows, retention cohorts, journey trees, segmentation with sampled filter values — you either add a layer like Mitzu, or build that methodology yourself in SQL and rely on the LLM to compose it correctly each time.

Can I use ClickHouse AI for funnels and retention?

An LLM can absolutely write a funnel or retention query against ClickHouse. Whether the methodology is right depends on the prompt, the grounding, and the day. The risk is not that the SQL fails to run — it usually runs — but that it answers the wrong question (window measured wrong, double-counted users, attribution joined off the wrong row). A deterministic engine that owns the methodology removes that class of error.

Is Mitzu open source?

Mitzu is a commercial SaaS product. The Enterprise tier supports self-hosted deployment in the customer's own infrastructure. Pricing is per editor seat with unlimited events on every tier — see the pricing page for current details.

Where does the data live in either tool?

In your warehouse. Both architectures are warehouse-native: ClickHouse AI by composition (the stack reads ClickHouse directly), Mitzu by design (the agent reads the warehouse via the deterministic engine). Neither moves data into a vendor silo. Compliance, data residency and cost control all stay on your side of the line.

Related reading

• Product Analytics with ClickHouse and Mitzu
• Top 5 Product Analytics tools for ClickHouse
• ChatGPT vs AI Analytics Agent
• Warehouse Native vs First-Generation Product Analytics
• Agentic Analytics Platforms Compared
• Mitzu Semantic Layer
• Mitzu Product Analytics

References

• ClickHouse — Agentic Data Stack (clickhouse.com/ai)
• ClickHouse blog — The AI-first data warehouse (DWAINE case study)
• LibreChat
• Langfuse
• Model Context Protocol
• Mitzu documentation (docs.mitzu.io)