PostHog AI vs Mitzu: Max AI Inside PostHog vs One Governed Analytics Platform on Your Warehouse

Use this comparison if you are evaluating PostHog AI and want to see how it differs from a governed analytics platform on your warehouse: who writes the SQL, what data the agent can reach, and whether product metrics, business KPIs and experiment results come from the same definitions.

PostHog has shipped one of the more ambitious agentic offerings in product analytics. Max AI is an AI agent that works within the PostHog platform: a single-loop architecture, agent modes for SQL, Analytics and CDP, and an MCP server exposing HogQL to external IDE agents. Mitzu is one analytics platform on your warehouse for BI, product analytics and experiment analysis, governed by the data team. It reads the customer's data warehouse in place, and its agent doesn't write SQL: a deterministic query engine does, from a typed analysis specification. This piece walks the two architectures side by side, with SQL examples for a question both tools can answer.

What is PostHog's agentic offering?

PostHog's agent is Max AI, a chat that lives inside the PostHog app and can edit filters, create insights, build dashboards, write HogQL, summarize session replays, and reason about experiments. The architecture handbook describes a single-loop pattern (one agent, full conversation context, dynamic mode-switching) inspired by Claude Code, with agent modes (SQL, Analytics, CDP) that load domain-specific tools and prompts on demand. PostHog's engineering team has written candidly about rebuilding it twice before landing on this shape.

The SQL story is central. PostHog's blog and docs are explicit that SQL is the semantic layer LLMs reason in best, so the agent is built around authoring HogQL (PostHog's SQL dialect), grounded by tools that introspect the taxonomy, event and property definitions, and existing insights. The MCP server exposes the same surface to external agents: run HogQL queries, manage Data Warehouse views, sync sources, explore schema.

• Single-loop agent: one agent with mode-switching (SQL, Analytics, CDP, Product), no black-box sub-agents.
• HogQL authoring: the LLM writes queries against PostHog's event store, Data Warehouse, and linked external sources (Postgres, Stripe, HubSpot via PostHog connections).
• Grounding tools: read_taxonomy, read_data, search for events, properties, schema, billing context, existing insights.
• In-app surfaces: chat is present across filter editing, insight building, SQL editor, replay summarization and experiment readouts.
• MCP server: the same agent surface for external IDE agents (Cursor, Claude Code, etc.) running HogQL inside PostHog.

The data scope is PostHog. Events land in PostHog's ingestion pipeline, sit in PostHog's event store, and the agent reasons over that store (plus whatever has been linked into PostHog's Data Warehouse). External sources can be synced in via PostHog connectors, but the agent's center of gravity is the PostHog environment: that is where the schema, taxonomy and definitions live.

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 PostHog, it answers product questions with funnels, retention, journeys and cohorts, with an agent on top. Unlike PostHog, it reads data in place in the warehouse, and the same governed definitions also power KPI dashboards on business metrics and A/B test analysis.

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.

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.

PostHog 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?"

PostHog: HogQL the LLM might generate

-- Plausible Max AI output against PostHog's events table.
-- HogQL — PostHog's SQL dialect. Methodology depends on prompt + grounding.
WITH signups AS (
  SELECT person_id,
         min(timestamp)                                       AS signup_at,
         argMin(properties.channel, timestamp)                AS channel
  FROM events
  WHERE event = 'signup'
    AND timestamp >= now() - INTERVAL 30 DAY
  GROUP BY person_id
),
activations AS (
  SELECT person_id, min(timestamp) AS activated_at
  FROM events
  WHERE event = 'activated'
    AND timestamp >= now() - INTERVAL 37 DAY
  GROUP BY person_id
)
SELECT s.channel                                              AS 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 ON a.person_id = s.person_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 session, 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.

PostHog's grounding (taxonomy lookups, query examples loaded at session start) reduces the failure rate; it doesn't eliminate the class of error.

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, against whichever warehouse the customer connected:

-- 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 across every supported warehouse; 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.

Other analyses Mitzu produces deterministically

The same pattern (typed specification in, engine-generated SQL out) covers the rest of the product analytics surface. Sketches below; real outputs are dialect-specific to the warehouse.

-- Retention: weekly cohorts of "signup" users returning via any "active" event,
-- 8-week window, segmented by acquisition channel.
WITH cohort AS (
  SELECT user_id,
         date_trunc('week', min(event_time)) AS cohort_week,
         any(properties['channel'])          AS channel
  FROM events
  WHERE event_name = 'signup'
    AND event_time >= now() - INTERVAL 70 DAY
  GROUP BY user_id
),
returns AS (
  SELECT c.user_id,
         c.channel,
         c.cohort_week,
         floor(date_diff('day', c.cohort_week, e.event_time) / 7) AS week_index
  FROM cohort c
  INNER JOIN events e
    ON e.user_id = c.user_id
   AND e.event_name = 'active'
   AND e.event_time >= c.cohort_week
   AND e.event_time <  c.cohort_week + INTERVAL 56 DAY
)
SELECT channel,
       cohort_week,
       week_index,
       count(DISTINCT user_id) AS retained_users
FROM returns
GROUP BY channel, cohort_week, week_index
ORDER BY cohort_week, week_index;

-- Cohort + warehouse join: users who completed checkout this month,
-- enriched with subscription tier from the billing fact table — no ETL.
SELECT e.user_id,
       max(e.event_time)              AS last_checkout_at,
       b.subscription_tier,
       b.mrr_usd
FROM events e
INNER JOIN dim_billing_subscriptions b
  ON b.user_id = e.user_id
 AND b.is_current
WHERE e.event_name = 'checkout_completed'
  AND e.event_time >= date_trunc('month', now())
GROUP BY e.user_id, b.subscription_tier, b.mrr_usd
ORDER BY mrr_usd DESC;

Retention specifications carry the cohort definition, return event, granularity and window. Cohorts can pull dimension data from warehouse tables modeled in dbt (billing, CRM, support) without exporting events into a vendor. PostHog's Max AI can reach external sources after they're linked into PostHog's Data Warehouse; Mitzu reads them in place. The same applies to experiments: if a feature-flag tool writes exposure events to the warehouse, Mitzu reports each test's lift, 95% interval and guardrails on the same revenue and conversion metrics as the KPI dashboard.

UI differences

Both products put chat front and center, but the operating model around the chat is different. PostHog is a SaaS application: events live in PostHog, and the chat helps you build and edit PostHog insights, dashboards, replays, flags and experiments. The output of an answer is usually a PostHog artifact (an Insight, a Dashboard) anchored to PostHog's data model.

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, cohorts), 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. Every answer surfaces the engine-generated SQL for verification. In Slack, a PM asking a question in #growth gets the same answer they'd get in the app; an external assistant (Claude, ChatGPT, Cursor, GitHub Copilot) reaching Mitzu over MCP gets the same governed answer; and monitoring agents review dashboards on a schedule and email the team when something moves.

Advantages and trade-offs

PostHog (Max AI)

Mitzu

Capability scorecard

Where each tool stands on governed metrics and BI, on product analytics and experiment analysis, and on the agents. ✅ supported and idiomatic. ❌ not supported, or possible only via workaround.

When to choose PostHog, Mitzu, or both?

Both answer product questions with an agent, but they point at different teams. The choice usually falls out of two questions: where are your events and business data today, and who should own the definitions that product metrics, KPIs and experiment results use?

• Choose PostHog when you want a single SaaS that covers product analytics, session replay, feature flags and experiments; when the engineering team is comfortable with PostHog as the center of gravity for product data; when greenfield speed matters more than warehouse joins.
• Choose Mitzu when events are already in a warehouse (or will be) alongside billing, CRM and support data; when the data team owns the modeling layer (dbt, metric definitions) and wants KPI dashboards, product analytics and A/B test results on the same governed metrics; when methodology must be deterministic and reproducible across the app, Slack and external AI assistants.
• Run both when PostHog Cloud earns its place for session replay and feature flags but KPI reporting, product analysis and experiment readouts need to run on warehouse data joined to the rest of the business. PostHog keeps replay and flag delivery; Mitzu handles the governed analysis.

FAQ

Is Max AI a text-to-SQL tool?

Effectively yes for the SQL mode: Max AI writes HogQL against PostHog's event store and Data Warehouse, grounded by taxonomy and schema introspection. PostHog's own engineering writing makes this explicit: SQL is the semantic layer the LLM is best at, so the agent is built around authoring queries. Mitzu's architecture is the opposite: the agent does not write SQL. It assembles analysis specifications; a deterministic engine emits the SQL.

Does Mitzu replace PostHog?

For the analytics layer, when events are in the warehouse: Mitzu covers product analytics and adds KPI dashboards on governed business metrics and A/B test analysis on the same definitions. PostHog's session replay, feature flags and surveys aren't Mitzu's scope, and Mitzu does not assign experiment variants. Many teams keep PostHog Cloud for those surfaces and run Mitzu on the warehouse for analysis. See the broader Mitzu vs PostHog comparison for the platform-level view.

Can Max AI answer questions across billing, CRM and support data?

Only for the sources explicitly linked into PostHog's Data Warehouse (Postgres, Stripe, HubSpot and similar connectors). The agent doesn't reach into a customer's full warehouse the way a warehouse-native tool does. Mitzu reads the warehouse in place, so behavioral events join naturally to billing, CRM, support and any dbt model already there.

How is Mitzu's MCP server different from PostHog's MCP server?

PostHog's MCP server exposes HogQL and Data Warehouse management to IDE agents: the surface is SQL over PostHog. Mitzu's MCP server gives an assistant one tool, Mitzu's analytics agent, which answers on the governed metrics with the SQL behind it, generated by the deterministic engine over the customer's warehouse. Each person sees only what their Mitzu role allows. An external agent reaching Mitzu over MCP gets the data team's definitions and methodology; reaching PostHog over MCP gets HogQL on PostHog's data.

Where does the data live in either tool?

PostHog: in PostHog's event store and Data Warehouse, plus whatever has been linked in via connectors. Mitzu: in the customer's warehouse, full stop. The architectural split has direct knock-on effects on pricing (per event vs Editor seats with unlimited events), compliance (vendor storage vs customer-controlled), and join richness (PostHog-linked sources vs everything already modeled in the warehouse).

Related reading

• Mitzu vs PostHog: platform-level comparison
• ClickHouse AI vs Mitzu
• Warehouse Native vs First-Generation Product Analytics
• Agentic Analytics Platforms Compared
• ChatGPT vs AI Analytics Agent
• Mitzu BI and Warehouse Metrics
• Mitzu Experiment Analysis
• Mitzu Semantic Layer
• Mitzu Product Analytics

References

• PostHog docs: Max AI
• PostHog handbook: AI platform architecture
• PostHog docs: Run SQL, manage views, and sync sources with MCP
• PostHog newsletter: What we wish we knew about building AI agents
• Mitzu documentation (docs.mitzu.io)