TL;DR
You do not need to copy event data out of Snowflake to get product analytics. Warehouse-native tools query the tables you already have, in place. Mitzu connects to Snowflake with a read-only user, generates the SQL for funnels, retention, and segmentations, and runs every query inside your Snowflake account. Query compute runs in your warehouse and appears on your Snowflake bill, under your control; Mitzu's pricing is seat-based with unlimited events (as of August 2026).
Your event data is already in Snowflake, and you want funnels, retention, and cohort analysis without copying that data into a separate analytics tool. That is exactly what warehouse-native product analytics does. Mitzu connects to Snowflake with a read-only user, generates the SQL for each analysis, and runs every query inside your Snowflake account. Event data is never ingested, duplicated, or stored outside your warehouse.
There is no tracking migration and no new pipeline. If events land in Snowflake today — from Segment, Snowplow, RudderStack, GA4 or Firebase exports, dbt models, or your own backend — those tables are the analytics source, as they are. The full mechanism is documented at docs.mitzu.io: warehouse-native architecture.
How product analytics runs inside Snowflake?
Mitzu is an agentic product analytics platform that runs on your data warehouse and answers behavioural questions through natural-language conversation, without writing SQL. Every analysis — a funnel, a retention curve, a segmentation — is an analysis specification: events, filters, breakdowns, time windows. A deterministic query engine turns the specification into SQL, and Snowflake executes it. Only aggregated results come back; raw event rows stay where they are.
- Connect — a Snowflake user with read access to the schemas that hold your event tables. Mitzu validates the connection with a
SELECT 1;and never asks for write access to your data. - Configure — the Configuration Agent scans your warehouse, identifies event and dimension tables (it recognises Segment
tracks, Snowplow events, GA4 exports, and Firebase schemas), and builds a semantic layer specialised for product analytics. You review; nobody hand-writes YAML. See the Mitzu semantic layer. - Ask — funnels, retention, segmentations, and journeys through the UI or the Analytics Agent, in the app, in Slack, or over MCP. A single configured event table is enough for a first insight.
Because analysis runs where the data lives, behavioural events join natively to everything else already modelled in Snowflake — billing, CRM, and support tables — without a sync job. That is the class of question a separate analytics store cannot answer, because the store only holds what was sent to it. More on the architecture in warehouse-native vs first-generation product analytics.
What it costs to run?
The honest answer to the compute question: queries run in your Snowflake account, so query compute appears on your Snowflake bill, under your control. You choose the virtual warehouse Mitzu uses and its size. Sampling and resolution settings bound how much data each query scans, and cached results keep dashboards from re-running queries whose results are still fresh.
Mitzu's own pricing is seat-based and does not meter events or queries — plans start at $149/month with unlimited events (as of August 2026; see pricing). The trade against per-event analytics pricing is structural: your analytics bill stops scaling with your product's success and becomes a function of seats plus the warehouse compute you already govern.
What access you have to grant?
Mitzu needs read access to the databases, schemas, and tables you configure — nothing more. The recommended setup is a dedicated read-only Snowflake user with SELECT on the event and dimension schemas, plus usage on a virtual warehouse to run queries. Mitzu never modifies data in your warehouse, and what it stores on its side is semantic-layer metadata: event names, property names, and sampled filter values — not event rows.
For compliance-sensitive teams the same read-only posture extends to the AI surfaces: the model receives aggregated results and metadata, and raw event data never leaves the warehouse for the model. Details in AI data & privacy on the docs site.
What about events already in a third-party analytics tool?
Most Snowflake-first teams are not starting from zero — they have history in a hosted analytics product. Two things are true at once. Going forward, nothing needs to change: if your CDP or pipeline already lands events in Snowflake, analysis simply moves to those tables. Historically, most hosted tools offer raw-event export, and once exported into Snowflake those rows become ordinary event tables Mitzu can query like any other.
The migration mechanics — what changes, what does not, and how to run both tools in parallel during the switch — are covered in migrating from Mixpanel when your data is already in the warehouse.
The same approach on BigQuery
Everything above applies to BigQuery unchanged: Mitzu connects with a service account carrying four read-scoped roles (BigQuery User, Data Viewer, Job User, and Read Session User), queries run as BigQuery jobs in your project, and compute is billed by Google Cloud under your existing controls. GA4's native BigQuery export is a common starting point. See product analytics with BigQuery and Mitzu.
The same approach on Databricks
On Databricks, Mitzu connects to a SQL warehouse with token-based authentication and queries Delta tables in place — including dbt-modelled ones. Serverless and PRO SQL warehouses are the recommended engines. See product analytics with Mitzu and Databricks.
The same approach on Redshift
Redshift works the same way: a dedicated read-only database user, queries executed in your cluster or serverless workgroup, compute on your AWS bill. Mitzu also connects to Athena, PostgreSQL, ClickHouse, Trino, Starburst, Firebolt, and Microsoft Fabric — the full list is at warehouse integrations.
FAQ
Can I run product analytics directly on Snowflake?
Yes. Warehouse-native product analytics tools like Mitzu connect to Snowflake with a read-only user and run funnels, retention, segmentation, and journey queries inside your Snowflake account. Event data is not copied into a separate analytics store.
Do I need a new tracking setup or SDK?
No. Mitzu analyses the event tables already in your warehouse — Segment, Snowplow, RudderStack, GA4 or Firebase exports, dbt models, or custom backend events. The only requirements on an event table are a user identifier and an event timestamp.
Who pays for the Snowflake compute?
You do, on your existing Snowflake bill — the queries run in your account, on a virtual warehouse you choose and size. Mitzu's own pricing is seat-based with unlimited events (as of August 2026), so total cost is seats plus compute you already govern.
How long does setup take?
Configuration is automated rather than a data engineering project: the Configuration Agent scans the warehouse, proposes event and dimension tables, and builds the semantic layer. A single configured event table is enough to create the first insight, and most workspaces are configured in minutes rather than weeks.
