Snowflake Cortex vs Mitzu: Agentic SQL on Snowflake vs Agentic Product Analytics on the Warehouse

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

Snowflake has been steadily building out an agentic stack — Cortex Agents, Cortex Analyst, Cortex Search, and Snowflake Intelligence — and positioning the result as the "control plane for the agentic enterprise." That makes "Snowflake Cortex vs Mitzu" a fair question to ask: both run on the warehouse, both promise an agentic analytics workflow, and Snowflake-using teams sit squarely in Mitzu's ICP. The honest framing is that they sit at different layers. Cortex is general-purpose agentic SQL on Snowflake. 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 Snowflake as a first-class warehouse.

What is Snowflake Cortex?

Snowflake Cortex is the umbrella name for Snowflake's in-warehouse AI features. The agentic surface area is built from a small set of composable pieces:

• Cortex Agents — orchestration layer. An agent plans a question, picks tools (Cortex Analyst for structured data, Cortex Search for unstructured, custom stored procedures, web search via Brave), reflects on results, and returns an answer. Exposed via REST API and the Snowsight chat UI.
• Cortex Analyst — fully-managed text-to-SQL over a YAML semantic model. The model defines logical tables, dimensions, facts, metrics, and relationships. LLMs (Claude and OpenAI, selected per query) author SQL against it.
• Cortex Search — retrieval over unstructured data (PDFs, docs, transcripts).
• Snowflake Intelligence — the business-user surface. A "personal work agent" with MCP connectors to Gmail, Slack, Jira and Salesforce, deep research, and an iOS app.
• Cortex Code — Snowflake-native coding agent for builders, with VS Code and Claude Code plugins.

An April 2026 update collapsed two of the layers: Cortex Agents that use a Cortex Analyst semantic view as a tool now generate SQL directly rather than delegating to the Analyst service as a separate step. Lower latency, fewer round-trips. The architecture is otherwise unchanged: an LLM authors the SQL, grounded by a YAML semantic model the data team writes.

The stack is general-purpose by design. The same architecture handles a quarterly revenue question, a support-ticket summary, a contract search and a sales-pipeline dashboard. It is not pitched specifically at product analytics, and the YAML semantic model does not ship native funnel, retention, segmentation or cohort primitives. Methodology lives in whatever SQL the LLM produces for each question.

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. Snowflake is one of the supported warehouses — see AI Analytics for Snowflake (2026) for a deeper walk-through.

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.

Snowflake Cortex 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?"

Snowflake Cortex: SQL the LLM might generate

-- Plausible Cortex Analyst output against a Snowflake events table.
-- Looks reasonable; methodology depends on the YAML semantic model + prompt.
WITH signups AS (
  SELECT user_id,
         MIN(event_time)               AS signup_at,
         ANY_VALUE(properties:channel::string) AS channel
  FROM analytics.events
  WHERE event_name = 'signup'
    AND event_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
  GROUP BY user_id
),
activations AS (
  SELECT user_id, MIN(event_time) AS activated_at
  FROM analytics.events
  WHERE event_name = 'activated'
    AND event_time >= DATEADD('day', -37, CURRENT_TIMESTAMP())
  GROUP BY user_id
)
SELECT s.channel,
       COUNT(*)                                                          AS signups,
       COUNT_IF(a.activated_at <= DATEADD('day', 7, s.signup_at))         AS activated_in_7d,
       ROUND(activated_in_7d / NULLIF(signups, 0) * 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 YAML model and the prompt. A different prompt run, a different model selection, or a slightly different semantic model entry 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_VALUE(properties:channel::string)    AS channel
  FROM analytics.events
  WHERE event_name = 'signup'
    AND event_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
    AND event_time <  CURRENT_TIMESTAMP()
  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 analytics.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 <= DATEADD('day', 7, s1.step_1_at)
  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.

UI surfaces compared

Both platforms expose chat. The differences live in the artifacts the chat produces and where they can be reviewed.

Advantages and trade-offs

Snowflake Cortex

Mitzu

Capability scorecard

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

When to choose Snowflake Cortex, Mitzu, or both?

These are layers, not substitutes. Cortex gives you a general agentic interface to Snowflake. 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 Snowflake Cortex when the analytics surface is broad and cross-domain (finance, sales, support, ops alongside product), Snowflake is already the single source of truth, and you have the data-engineering cycles to author and maintain Cortex Analyst semantic models in YAML.
• 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 — especially if your data also lives in BigQuery, Databricks or ClickHouse.
• Run both when Snowflake is the system of record for a wide analytics surface and product analytics is one of several question types — let Cortex handle the long tail (and unstructured retrieval via Cortex Search) and let Mitzu specialise in the behavioural layer. Mitzu's remote MCP server can also be exposed to a Cortex Agent as a tool, so a Cortex orchestration can call out to Mitzu when the question is behavioural.

FAQ

Does Mitzu work with Snowflake?

Yes. Snowflake is a first-class supported warehouse. Mitzu reads event tables and dbt-modelled tables in place — no data movement, no per-event pricing. See AI Analytics for Snowflake (2026) for the broader landscape on Snowflake.

Does Snowflake Cortex replace Mixpanel, Amplitude or other product analytics tools?

Not by itself. Cortex is general-purpose agentic analytics on Snowflake 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 Cortex Analyst for funnels and retention?

An LLM can absolutely write a funnel or retention query against Snowflake. Whether the methodology is right depends on the YAML semantic model, the prompt, the model selection that day, and the schema in front of it. 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.

How does Cortex Analyst's semantic model differ from Mitzu's semantic layer?

Cortex Analyst's semantic model is a YAML file describing logical tables, dimensions, facts, metrics and relationships — a BI-shaped model designed to give the LLM a grounded vocabulary for text-to-SQL. Mitzu's semantic layer stores events, event properties, entities (users, sessions, accounts), dimension properties on those entities, and sampled property values for filters. It is built automatically by the Configuration Agent and specialised for product analytics, not authored as YAML by data engineers.

Is Mitzu self-hostable inside our Snowflake account?

Mitzu is a commercial SaaS product. The Enterprise tier supports self-hosted deployment in the customer's own infrastructure for cases where SaaS analytics aren't acceptable. Mitzu reads Snowflake from there in the same way the SaaS version does — no data movement, no per-event pricing. 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?

Inside Snowflake. Both architectures are warehouse-native: Cortex by being a Snowflake-native feature, Mitzu by design (the agent reads Snowflake via the deterministic engine). Neither moves data into a vendor silo. Compliance, data residency and cost control all stay on the customer's side of the line.

Related reading

• AI Analytics for Snowflake (2026)
• ClickHouse AI vs Mitzu
• ChatGPT vs AI Analytics Agent
• Warehouse Native vs First-Generation Product Analytics
• Agentic Analytics Platforms Compared
• Mitzu Semantic Layer
• Mitzu Product Analytics

References

• Snowflake docs — Cortex Agents
• Snowflake docs — Cortex Analyst
• Snowflake release notes — Improved SQL generation in Cortex Agents (April 2026)
• Snowflake Cortex AI — product page
• Snowflake press release — Snowflake Intelligence and Cortex Code (April 2026)
• Mitzu documentation (docs.mitzu.io)