Warehouse-native architecture
Mitzu runs product analytics directly on your data warehouse. Mitzu connects to your warehouse with read-only credentials, generates SQL, and runs every analytical query inside the warehouse itself. Event data is never ingested, duplicated, or stored outside your warehouse.
This page describes the mechanism: what Mitzu queries, what Mitzu stores, who pays for compute, and what access Mitzu needs.
How queries run
Every insight in Mitzu — a funnel, a retention chart, a segmentation, a journey — is an analysis specification: the events, filters, breakdowns, and time windows that define it. Mitzu's query engine translates that specification into SQL. Your warehouse executes the SQL and returns aggregated results.
- Mitzu generates the SQL. Your warehouse executes it.
- Results returned to Mitzu are aggregates — counts, rates, and time series — not raw event rows.
- Every generated query is inspectable: the
Show SQLoption on the Insights page displays the exact SQL Mitzu produced, and the Query Admin tab lists the queries Mitzu has sent to your warehouse, with warehouse-reported status and statistics.
What Mitzu queries
Mitzu connects to the following data warehouses and query engines:
- Snowflake
- Google BigQuery
- Databricks
- AWS Redshift
- AWS Athena
- PostgreSQL
- ClickHouse
- Self-hosted Trino / Presto
- Starburst
- Firebolt
- Microsoft Fabric
Teams without event data in a warehouse can also start from an uploaded CSV. The warehouse integrations page covers connection settings for each engine.
Mitzu works on raw event tables as well as modeled tables. dbt-modeled tables, Segment tracks tables, Snowplow events, GA4 exports, and Firebase analytics tables are all queried in place — see data modeling.
What Mitzu never copies
Mitzu never copies event data out of your warehouse, and never modifies data in it. Raw event rows are not ingested, duplicated, or stored outside your warehouse.
What Mitzu stores on its side is the semantic layer and your saved work:
- Semantic-layer metadata — event names, event and dimension property names, and sampled filter values discovered during indexing. Sampled filter value lists are capped at 500 values per property; high-cardinality columns are not extracted.
- Saved assets — insight definitions, dashboards, and cohort definitions. A cohort is stored as its definition, not as a list of user rows.
- Aggregated results — cached chart results, so a dashboard can render without re-querying your warehouse. Raw event data is not part of any cache.
The AI Data & Privacy page describes the same isolation guarantees for the agent surfaces: raw event data never leaves your warehouse for the model.
Who pays for compute
Queries run in your warehouse, so query compute appears on your warehouse bill, under your control. Mitzu's own pricing is seat-based and does not meter events or queries.
You control the cost of that compute directly:
- Warehouse sizing stays your decision — Mitzu queries whatever engine and size you configure.
- Performance settings control sampling and resolution, which bound how much data each query scans.
- Cached results and auto-refresh windows on dashboards avoid re-running queries whose results are still fresh.
- The Query Admin tab shows warehouse-reported statistics — bytes processed, rows returned, elapsed time — for every query Mitzu runs, and lets you cancel running queries.
What read access Mitzu needs
Mitzu needs read access to the databases, schemas, and tables you configure in your workspace — nothing more. We strongly recommend creating a dedicated read-only user for Mitzu in your data warehouse; see connection settings.
Concrete, per-warehouse requirements where the platform defines named roles:
| Warehouse | Required access |
|---|---|
| BigQuery | A service account with the BigQuery User, BigQuery Data Viewer, BigQuery Job User, and BigQuery Read Session User roles — see BigQuery |
| AWS Athena | An IAM user with Athena query execution, Glue catalog read, and S3 read access to your data, plus write access to the S3 query-results bucket only — see AWS Athena |
| Trino | A read-only rule for the configured catalogs in the System Access Control file — see Trino |
| Starburst | A user and role with read-only privileges on your data catalog — see Starburst |
| All others | A dedicated user with SELECT access to the configured schemas and tables — see the connector pages |
Connecting validates with a SELECT 1; — Mitzu asks for no write access to your data.
How the semantic layer is configured
You do not hand-author the semantic layer. The Configuration Agent builds it by scanning your warehouse:
- It identifies event tables and dimension tables, recognizing vendor patterns such as Segment
tracks, Snowplow events, GA4 event tables, and Firebase analytics. - It maps user and group identifiers, timestamps, and event names, and configures the tables it is confident about automatically. Ambiguous tables are confirmed with you.
- Indexing then populates the semantic layer with the events, properties, and sampled filter values the query engine uses to answer questions.
Configuring a single event table is enough to create your first insight, and most workspaces are configured in minutes. As your warehouse evolves, re-running the agent keeps the semantic layer in sync.
Deployment options
Mitzu Cloud runs at app.mitzu.io and connects to your warehouse over the network. For stricter isolation requirements, the Mitzu team can deploy a private Mitzu instance into your own cloud, which can be isolated from the Internet — see connect Mitzu. In both deployments the architecture is the same: queries run in your warehouse, and event data stays there.