BigQuery AI vs Mitzu: Gemini-Written SQL on BigQuery vs a Governed Analytics Platform on the Warehouse

Use this comparison if you are evaluating BigQuery AI for analytics on BigQuery and want to see how it differs from a governed analytics platform on the same project: who writes the SQL, how metrics are defined, and what each runs beyond a chat answer.

Google has been repositioning BigQuery as an autonomous data-to-AI platform for the agentic era, anchored by BigQuery AI, Conversational Analytics and Gemini. That makes "BigQuery AI vs Mitzu" a fair question: both answer plain-English questions on BigQuery data, and BigQuery teams sit squarely in Mitzu's audience. BigQuery AI is general-purpose, Gemini-written SQL on Google's warehouse. Mitzu is one analytics platform on the warehouse for BI, product analytics and experiment analysis, governed by the data team, with an AI agent whose SQL comes from a deterministic engine. BigQuery is one of the warehouses Mitzu connects to.

What is BigQuery AI?

BigQuery AI is the umbrella name for Google Cloud's agentic offering on top of BigQuery. The public surface gathers several capabilities together: Conversational Analytics for chatting with your data in natural language, Data Agents for science and engineering workflows, BigQuery Graph as a semantic-layer preview, proactive agentic workflows that watch for metric shifts, and the Google Cloud Data Agent Kit, a portable suite of MCP tools and skills.

The clearest reference implementation is Conversational Analytics, generally available inside BigQuery Studio and available through Looker Studio Pro, Gemini Enterprise and the Conversational Analytics API. Gemini writes SQL against BigQuery grounded in schema metadata, custom business instructions, verified queries and user-defined functions. According to Google's documentation, agents can be customized with knowledge sources (tables, views, graphs, UDFs), table and field annotations, processing instructions (synonyms, defaults, filters), and verified queries: patterns the LLM is told to follow for recurring business logic.

• Conversational Analytics (GA): Gemini-authored SQL with executive summaries, follow-up suggestions, and surfaced "thinking" steps for verification.
• Data Agents: a Data Science Agent for loading, cleaning and visualizing in BigQuery ML/DataFrames/Spark, plus a Data Engineering Agent for pipeline work.
• BigQuery Graph (preview): a semantic layer that maps entities, relationships and native measures, navigable by Conversational Analytics for higher-accuracy answers.
• Proactive agentic workflows (preview): detect metric shifts, run root-cause investigations, deliver scheduled briefings.
• Google Cloud Data Agent Kit (preview): MCP tools and skills that work in VS Code, Gemini CLI, Claude Code and any MCP-compatible client.

The architecture is general-purpose by design. Conversational Analytics is positioned for ad-hoc data exploration, forecasting (via AI.FORECAST), anomaly detection (AI.DETECT_ANOMALIES), text generation and graph-based relationship queries. It is not pitched at product analytics or experiment analysis, and the platform does not ship native funnel, retention, segmentation, cohort or experiment primitives. Methodology lives in whatever SQL Gemini writes, or in the LookML or BigQuery Graph model the data team builds and keeps current.

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 BigQuery AI, it answers plain-English questions on BigQuery data. Unlike BigQuery AI, the same governed definitions also run KPI dashboards, funnels, retention, journeys and A/B test analysis inside Mitzu.

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. BigQuery is one of the supported warehouses, alongside Snowflake, Databricks, Redshift, ClickHouse, PostgreSQL, Athena, Trino, Firebolt and Microsoft Fabric. See Top 5 Product Analytics Tools for BigQuery.

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.

BigQuery AI vs Mitzu: side-by-side

SQL examples: the same question, two paths

A governed KPI question such as "What was net revenue last quarter?" works in both once the metric is defined. The difference shows on the product question that usually comes next: "What is our 7-day signup-to-activation conversion rate, broken down by acquisition channel, for the last 30 days?"

BigQuery AI: SQL Gemini might generate

-- Plausible Gemini output via Conversational Analytics, BigQuery Standard SQL.
-- Looks reasonable; methodology depends on the prompt + grounding.
WITH signups AS (
  SELECT user_id,
         MIN(event_time)                                AS signup_at,
         ANY_VALUE(properties.channel)                  AS channel
  FROM `my_project.analytics.events`
  WHERE event_name = 'signup'
    AND event_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  GROUP BY user_id
),
activations AS (
  SELECT user_id,
         MIN(event_time) AS activated_at
  FROM `my_project.analytics.events`
  WHERE event_name = 'activated'
    AND event_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 37 DAY)
  GROUP BY user_id
)
SELECT s.channel,
       COUNT(*)                                                                     AS signups,
       COUNTIF(a.activated_at <= TIMESTAMP_ADD(s.signup_at, INTERVAL 7 DAY))         AS activated_in_7d,
       ROUND(SAFE_DIVIDE(
         COUNTIF(a.activated_at <= TIMESTAMP_ADD(s.signup_at, INTERVAL 7 DAY)),
         COUNT(*)
       ) * 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 prompt. A different prompt run, 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 Gemini conflated the lookback with the conversion window. None of these are SQL bugs. They are methodology choices an LLM is making implicitly, every time.

Verified queries and BigQuery Graph can constrain the surface, but every new variant of the question is a fresh authoring problem.

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)  AS channel
  FROM `my_project.analytics.events`
  WHERE event_name = 'signup'
    AND event_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
    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 `my_project.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 <= TIMESTAMP_ADD(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(SAFE_DIVIDE(
         COUNT(DISTINCT s2.user_id),
         COUNT(DISTINCT s1.user_id)
       ) * 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 as the agent's authored work, and the funnel can sit on the same dashboard as the revenue KPI it explains.

More analyses Mitzu turns into deterministic SQL

The same pattern (typed specification in, deterministic SQL out) covers the rest of the product analytics and experiment analysis surface. Three quick examples.

Weekly retention for a cohort

Spec: { cohort_event: "signup", return_event: "session_start", time_unit: "week", windows: 8, segment: "country = 'US'" }. The engine bins users by signup week, counts who came back in each subsequent week, and avoids the classic double-count when a user has multiple session_start events in the same bucket. The agent in BigQuery AI has to compose this from scratch every time, and there are at least three plausible weekly bucketings that would each look right at a glance.

Journey analysis from a starting event

Spec: { starting_event: "added_to_cart", depth: 5, time_window: "1d" }. The engine returns the top paths users take after adding to cart within 24 hours, with counts at each step. Journey methodology (ordered event sequences with branching) is the most error-prone shape for an LLM to author; a deterministic engine that has the methodology built in sidesteps the whole class of mistakes.

Impact analysis and A/B test results

Take "Did users exposed to the new pricing page convert better in the next 14 days?" Mitzu defines two cohorts (saw_new_pricing, did_not_see_new_pricing), measures trial-to-paid conversion in the same 14-day window relative to exposure, and surfaces the delta: same specification, same SQL, every run. The analytics agent can stitch this into a deep dive with multiple analyses: cohort definitions, segmentations, time-window comparisons, churn deltas. If the pricing page ran as an A/B test in your experimentation tool, Mitzu reads the exposures from BigQuery and reports lift against control with a 95% interval, a p-value corrected for multiple comparisons, guardrail metrics and health checks, on the same revenue metric the KPI dashboard uses.

UI differences

BigQuery AI primarily lives inside BigQuery Studio, with the Conversational Analytics panel attached to a notebook or dataset. Answers come back as executive summaries, raw data and Gemini-generated charts, with the SQL surfaced underneath for verification. The same agent can also be embedded in Looker Studio Pro reports, in Gemini Enterprise, or called via API. Configuration of data agents (knowledge sources, verified queries, business instructions) happens in BigQuery Studio.

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), 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. Product managers, growth leads and marketers reach the same agent in Slack by mentioning @mitzu in any channel and following up in the thread. The remote MCP server gives Claude, ChatGPT, Cursor and GitHub Copilot the same governed answers, and scheduled monitoring agents review dashboards and email the team when something moves. Every surface answers from the same definitions and the same deterministic engine, so the answer does not depend on where the question was asked.

Advantages and trade-offs

BigQuery AI

Mitzu

Capability scorecard

Where each tool stands on governed metrics and BI, on product analytics and experiment analysis, and on how people reach the agents.

When to choose BigQuery AI, Mitzu, or both?

Both answer plain-English questions on BigQuery data, so they overlap. BigQuery AI gives you a general agentic interface to the warehouse, deeply integrated with Google Cloud, with Gemini writing the SQL. Mitzu gives you one analytics platform where the same governed definitions run KPI dashboards, product analytics and experiment analysis, with a deterministic engine that keeps the methodology right. The right choice depends on which questions dominate the team's workload and how much the answers have to agree with each other.

• Choose BigQuery AI when the questions are broad and free-form across the whole warehouse, forecasting and anomaly functions matter, BigQuery is already the center of gravity, you want a Google-managed agent end to end, and you have the data-engineering cycles to staff BigQuery Graph or LookML modeling and verified-query libraries.
• Choose Mitzu when you want KPI dashboards plus funnels, retention, journeys and A/B test results on one set of definitions the data team governs; an agent that explains why a number moved (why did week-2 retention drop, did the new pricing page move trial-to-paid, which onboarding step has the highest drop-off) with SQL from a deterministic engine; scheduled agents that watch the KPIs; and the same answers in Slack and AI assistants.
• Run both when BigQuery AI already serves data scientists and engineers inside Google Cloud, and the data team wants governed KPI reporting, product analytics and experiment analysis for the rest of the company on the same BigQuery project.

FAQ

Does Mitzu work with BigQuery?

Yes. BigQuery is a first-class supported warehouse. Mitzu reads event, fact, dimension and dbt-modeled tables in place, with no data movement and no per-event pricing. See Top 5 Product Analytics Tools for BigQuery for the broader landscape.

Does BigQuery AI replace Mixpanel, Amplitude, or other product analytics tools?

Not by itself. BigQuery AI is general-purpose agentic analytics on warehouse data. For product analytics methodology specifically (funnels with conversion windows, retention cohorts, journey trees, segmentation with sampled filter values) and for experiment statistics, you either use a platform like Mitzu, where that methodology is built into the engine next to the KPI dashboards, or build it yourself in BigQuery Graph and verified queries and rely on Gemini to compose it correctly each time.

Can BigQuery AI do funnels and retention?

Gemini can write a funnel or retention query against BigQuery. Whether the methodology is right depends on the prompt, the grounding, and the day. The risk is not that the SQL fails to run (it usually runs) but that it answers the wrong question: a window measured wrong, double-counted users, attribution joined off the wrong row. A deterministic engine that owns the methodology removes that class of error.

What is BigQuery Graph and how does it compare to Mitzu's semantic layer?

BigQuery Graph (preview) is a semantic layer where data engineers model entities, relationships and native measures so Conversational Analytics can reason over a curated business map instead of raw tables. It is BI-shaped (metrics, dimensions, joins, relationships) and it is hand-authored. Mitzu's semantic layer holds metrics such as net revenue, orders and margin on fact and dimension tables, plus events, event properties, entities, dimension properties and sampled property values. Mitzu drafts it from the warehouse and dbt models, the data team reviews and owns it, and it runs product analytics and experiment analysis as well as KPI reporting.

Different shape, different operational cost.

Is Mitzu open source?

No. Mitzu is a commercial SaaS product. The Enterprise plan supports self-hosted deployment in the customer's own infrastructure. Every plan includes Editor seats and unlimited events, with no per-event pricing; see the pricing page for current details.

Where does the data live in either tool?

In BigQuery. Both architectures are warehouse-native: BigQuery AI by construction (Gemini queries BigQuery directly), Mitzu by design (the agent reads BigQuery through 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

• Top 5 Product Analytics Tools for BigQuery
• ClickHouse AI vs Mitzu
• ChatGPT vs AI Analytics Agent
• Warehouse Native vs First-Generation Product Analytics
• Agentic Analytics Platforms Compared
• Mitzu BI and Warehouse Metrics
• Mitzu Experiment Analysis
• Mitzu Semantic Layer
• Mitzu Product Analytics

References

• Google Cloud blog: Unveiling new BigQuery capabilities for the agentic era
• Google Cloud blog: Conversational Analytics in BigQuery
• BigQuery documentation: Conversational analytics overview
• Google Cloud blog: Build data agents with the Conversational Analytics API
• BigQuery: AI data platform
• Mitzu documentation (docs.mitzu.io)