AI analytics for Snowflake, without moving your data
Mitzu is an AI analytics platform that runs on your Snowflake account. Its analytics agent answers questions about the whole customer journey, from campaign and signup to product usage, orders and revenue, and every answer is a query that runs in your own Snowflake virtual warehouse, with the SQL shown. Nothing is copied out of Snowflake, and the SQL comes from a deterministic engine, not from the language model.
Your data team defines the metrics once on its Snowflake tables. KPI dashboards, funnels, retention, A/B test results and answers in Slack or your own AI assistant all use those definitions.
How zero-copy AI analytics works on Snowflake
Someone asks a question
In the Mitzu app, by mentioning @mitzu in Slack, or from Claude, ChatGPT, Cursor or another assistant through Mitzu's MCP server. For example: “Why did trial-to-paid conversion drop for paid-search signups last week?”The agent builds an analysis specification
It finds the right events, metrics and properties in Mitzu's semantic layer, which is indexed from your Snowflake tables, and fills in the analysis: funnel steps, conversion window, breakdowns and date range.The engine writes the SQL, Snowflake runs it
Mitzu's deterministic query engine turns the specification into SQL. Snowflake executes it on the virtual warehouse and role you assigned to Mitzu, inside your account.Aggregates come back, with the query attached
Mitzu receives counts, rates and time series, not event rows. The agent explains the result as a chart and a summary, and the exact SQL is one click away.
Stays in Snowflake
- Raw event tables, whether from Segment, Snowplow or your own pipeline
- Orders, subscriptions, revenue and CRM tables
- dbt models and the transformations behind them
- Row access and masking policies, enforced by Snowflake at query time
Stored by Mitzu
- Semantic-layer metadata: event, property and table names, plus sampled filter values (at most 500 per property)
- Saved insights, dashboards and cohort definitions, stored as definitions, not user lists
- Cached aggregated results, so dashboards open without re-querying Snowflake
Verified SQL: the agent picks the analysis, the engine writes the query
In most AI analytics tools on Snowflake, a language model writes a fresh SQL query for every question. The query usually runs. The problem is methodology: a funnel without a conversion window, a retention chart that doesn't bucket cohorts, a segmentation that counts the same customer twice. Those errors return a plausible number, and nobody notices.
Mitzu's agent never writes SQL. It assembles a typed analysis specification, and the same query engine that powers Mitzu's insights page compiles it into SQL, with funnel, retention, journey and experiment methodology built in. The language model can't introduce a methodology error into a query it never authored.
Analysts can check every step. Show SQL displays the exact query behind any chart, which you can paste into a Snowsight worksheet and run yourself. The Query Admin tab lists every query Mitzu has sent to Snowflake, with Snowflake-reported status and statistics. See how the agent works for the full division of labour.
An analysis specification, as the agent builds it
- analysis
- funnel
- steps
- signed_up → trial_started → subscription_paid
- window
- 14 days
- breakdown
- first-touch utm_source
- range
- last 90 days
Questions Snowflake teams ask, across the customer journey
Marketing
“Which campaigns brought customers who placed a second order within 30 days?”
Product
“Which onboarding step loses the most new workspaces, broken down by plan?”
Revenue
“Net revenue dropped last week. Which funnel step and which segment caused it?”
Retention
“Why did week-2 retention drop after the v2.3 release?”
Experiments
“Did the one-page checkout test lift conversion, and did refunds stay flat?”
Monitoring
“Every Monday at 9:00, email the growth team if activation falls below 30%, with the reason.”
What setup on Snowflake involves
Create a read-only user and role in Snowflake
Grant the role USAGE on a virtual warehouse and on the databases and schemas Mitzu should see, and SELECT on their tables. Mitzu needs no write access. A dedicated warehouse keeps Mitzu's credits separate.Enter the connection in Mitzu
Add your account identifier, the user, a password or a key-pair private key, and the warehouse and role to use. Mitzu tests the connection withSELECT 1. Step-by-step: Snowflake connection guide.Let the Configuration Agent map your tables
It scans the schemas you select, finds event and dimension tables (including Segment and Snowplow layouts), maps user and account identifiers and timestamps, and asks you about tables it isn't sure of. Indexing then samples property values for filters.Review metrics and roles, then invite the team
Mitzu drafts metric definitions such as net revenue or active accounts from your tables and dbt models; the data team reviews and owns them, and sets Mitzu roles for who sees what. Then connect Slack and MCP clients.
One configured event table is enough for a first funnel or retention chart. Teams without events in Snowflake yet can start from a CSV upload, but Mitzu is built for companies whose event and business data already land in a warehouse.
Cost, security and governance on Snowflake
Compute you control
Mitzu's queries run on the virtual warehouse you assign, so warehouse size, auto-suspend and resource monitors work exactly as for any other workload.
Fewer credits per dashboard
Cached aggregated results and dashboard refresh windows avoid re-running fresh queries. Sampling and time-resolution settings bound how much data a query scans.
Snowflake policies apply
Mitzu queries as the role you created, so row access policies and masking policies on that role apply to every chart and agent answer.
Roles on every surface
Mitzu roles decide what each person sees in dashboards, the agent, Slack, MCP clients and scheduled emails. Nobody needs their own Snowflake login.
What the AI model sees
Catalog metadata and aggregated results only. Raw event rows never leave Snowflake for the model, and your data is never used to train models.
Seat pricing, optional self-hosting
Mitzu is priced per seat, with no per-event or per-query metering. Teams with strict isolation needs can run a private Mitzu instance in their own cloud.
Mitzu vs Snowflake Cortex Analyst vs event-based analytics tools
| Capability | Mitzu on Snowflake | Snowflake Cortex Analyst | Mixpanel or Amplitude |
|---|---|---|---|
| Where the data lives | In your Snowflake account, queried in place | In your Snowflake account | Usually copied into the vendor's storage by SDKs or a warehouse sync |
| Who writes the SQL | A deterministic engine, from the agent's analysis specification | A language model, for each question | The vendor's own query engine |
| Where definitions come from | Drafted by Mitzu from your tables and dbt models, owned by the data team | A semantic model or semantic view the data team writes and maintains | A tracking plan and event schema inside the vendor tool |
| Funnels, retention, journeys | Built-in methodology in the engine | Composed by the model per question | Built in |
| KPI dashboards on revenue and orders | Governed metrics, dashboards by clicking or by asking | Charts in chat; dashboards through Streamlit apps or a BI tool | Only if revenue data is sent to the vendor |
| A/B test analysis | Lift, 95% interval, corrected p-values and guardrails on exposures in Snowflake | No built-in method; the model writes any statistics | For tests run in the vendor's own experimentation product |
| Joins to CRM, billing and support tables | Native: they're already in Snowflake | Yes, for modeled tables | Hard: each source has to be sent to the vendor |
| Pricing | Per seat; query compute on your Snowflake bill | Snowflake credits | Scales with event volume or tracked users |
| Where people use it | Mitzu app, Slack, MCP clients, monitoring-agent emails | Snowsight, Snowflake Intelligence, the Cortex Agents API | The vendor app and its built-in AI agent |
Cortex is a strong fit for free-form questions over any modeled Snowflake data, and Cortex Search covers documents and transcripts, which Mitzu does not analyze. For the full architecture and SQL examples, read Snowflake Cortex Analyst vs Mitzu.
AI analytics for Snowflake FAQ
Does Mitzu copy data out of Snowflake?
No. Mitzu sends SQL to Snowflake and receives aggregated results such as counts, rates and time series. Raw event rows are never exported, replicated or stored outside your account. Mitzu stores only semantic-layer metadata, saved definitions and cached aggregates.
Does the AI write the SQL that runs on Snowflake?
No. The analytics agent builds an analysis specification (events, metrics, funnel steps, windows, breakdowns) and Mitzu's deterministic query engine turns it into SQL. The same specification always produces the same SQL, and you can open that SQL on any chart.
What access does Mitzu need in Snowflake?
A dedicated read-only user and role with USAGE on a virtual warehouse and on the databases and schemas you choose, and SELECT on their tables. Mitzu authenticates with a password or a key pair and asks for no write access.
Which warehouse runs Mitzu's queries, and who pays?
The virtual warehouse you set in the connection, so the compute appears on your Snowflake bill. A dedicated warehouse with auto-suspend and a resource monitor keeps that spend separate and capped. Mitzu itself is priced per seat and does not meter queries.
Do Snowflake row access and masking policies apply?
Yes, for the role Mitzu connects with. Policies are enforced by Snowflake at query time, so masked columns stay masked in Mitzu charts and agent answers. Inside Mitzu, roles control what each person can see on every surface.
Does it work with dbt models and Segment or Snowplow data?
Yes. Mitzu queries raw event tables and dbt-modeled tables the same way, and the Configuration Agent recognizes common layouts such as Segment tracks tables and Snowplow events. Metric definitions can be inherited from dbt.
What does the AI model see from Snowflake?
Catalog metadata, such as event and property names, and aggregated query results. Raw event rows never leave Snowflake for the model, and your data is never used to train language models.
How is Mitzu different from Snowflake Cortex Analyst?
Cortex Analyst has a language model write SQL against a semantic model your team maintains. Mitzu's agent fills in analysis specifications that a deterministic engine compiles, with funnel, retention and experiment methodology built in, and adds KPI dashboards, A/B test analysis and monitoring agents on the same definitions.
Can marketing and product teams use it without SQL?
Yes. They ask in plain English in the app, in Slack, or from their own AI assistant through MCP, or build charts by clicking. Analysts keep the SQL behind every answer for review.
Can Mitzu analyze A/B tests stored in Snowflake?
Yes. If your experimentation tool or in-house assignment writes exposures to Snowflake, Mitzu reports lift, a 95% interval, corrected p-values, guardrail metrics and health checks on the same metrics as your dashboards. Your experimentation tool keeps assigning users.
How long does setup take?
Connecting Snowflake takes minutes, and one configured event table is enough for a first insight. Reviewing the drafted metric definitions and roles is the part worth the data team's time.
Can Mitzu run inside our own cloud?
Yes. Besides Mitzu Cloud, the Mitzu team can deploy a private instance into your own cloud environment, which can be isolated from the internet. The architecture is the same: queries run in Snowflake and data stays there.
Try Mitzu on your Snowflake data
Connect a read-only role, ask your first question, and check the SQL behind the answer.