You're on Metabase: Every Team Asks Its Own Questions. Data Workers Owns Whether the Answers Are True
Already on Metabase? Data Workers checks the tables under every question, model and metric, traces a wrong number to its cause and fixes it behind a named approval, with a receipt.
Your company runs on Metabase. Product managers build questions in the query builder, analysts write native SQL, and the official numbers live as metrics in the Library. Leadership gets the Company metrics dashboard by email every morning through a dashboard subscription. People ask Metabot in the app or @mention it in Slack, and since Metabase 60 your engineers reach the same content from Claude or Cursor through Metabase's built-in MCP server. Underneath: an app on Postgres, a replica for analytics, dbt and an orchestrator. Metabase lets every team ask. Data Workers owns whether the answer is true: it checks the tables after every run, traces a wrong number to the change that caused it, proposes the fix behind a named approval and verifies it with a receipt.
Key takeaways
- •Metabase keeps its job. Questions, dashboards, models, metrics, transforms, subscriptions and Metabot stay with the people who own them today.
- •Self-serve means many people trust one number. When the MRR metric in the Library is wrong, every question, dashboard and Metabot answer built on it is wrong the same way. Data Workers checks the tables under it after every run.
- •The fix lands where the cause is. Data Workers proposes the upstream change as a diff for its owner, routes it to a named approver and queues the rerun.
- •Data Workers changes nothing in Metabase. It works natively on Postgres, dbt and the orchestrator underneath; your team's own client reaches Metabase through its MCP server.
- •Start with one dashboard leadership reads, then climb from L0 manual to L4 autonomous per domain.
Metabase lets every team ask. Data Workers owns whether the answer is true.
Metabase made asking cheap, and that changes where errors land. A metric is a data source, an aggregation formula and a default time dimension, and everyone who picks it gets the same formula over the same table. If the table starts to mean something different, every answer moves together and nothing in Metabase looks broken: the query runs, the chart renders, Metabot explains it fluently.
Here is a Wednesday morning at a B2B SaaS company with Data Workers next to Metabase on a Postgres stack. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Tue 15:10 | GitHub | The app team merges the "annual plans" pull request: a migration adds year to the billing_interval values on subscriptions, and checkout offers annual billing at ten months' price |
| 15:25 | Amazon RDS for PostgreSQL | The deploy runs the migration. A launch email offers existing customers two months free for switching to annual |
| 16:00 to 23:59 | AWS DMS, Aurora PostgreSQL | 640 accounts switch. Each annual invoice carries ten months of price ($490 on a $49 plan). Ongoing replication copies subscriptions and invoices into raw_app on the analytics database as usual |
| Wed 02:00 | Airflow 2, dbt Core | The analytics_nightly DAG run runs dbt build. fct_mrr takes the latest invoice amount per active subscription and treats it as monthly. The run is green. MRR reads $1.49M instead of $1.21M |
| 02:35 | Data Workers | The post-run run_quality_check on stg_invoices and fct_mrr passes: no null or duplicate invoice_id, row counts above the minimum. The rows are valid. The MRR value the team records with monitor_metrics is up 23% against a 30-day baseline that moves under 1% a day, and it is flagged |
| 02:41 | Data Workers, Slack | The dbt manifest shows no model changed since the last good run, so diagnose_incident points upstream. trace_cross_platform_lineage follows fct_mrr back to raw_app.invoices; blast_radius_analysis lists fct_revenue_by_plan, fct_net_revenue_retention and, from context-graph notes the team recorded, the Company metrics dashboard and MRR metric. Another note adds that the metric reads mrr_daily, a Metabase transform. send_slack_alert posts to #data-oncall with the evidence and a check to run |
| 06:00 | Metabase | The daily transform job rebuilds mrr_daily from fct_mrr |
| 07:30 | Metabase | The dashboard subscription emails Company metrics, with a PDF, to the leadership list: MRR $1.49M, up 23% |
| 07:52 | Slack, Metabot | The CEO @mentions Metabot: why did MRR jump? Metabot answers from the MRR metric that the Pro plan drove the growth. It is faithful to the data; the data is wrong. The analytics engineer replies with the incident link |
| 08:00 | Aurora PostgreSQL | The analytics engineer runs the check Data Workers sent: SELECT s.billing_interval, count(*), sum(i.amount_usd) FROM raw_app.invoices i JOIN raw_app.subscriptions s USING (subscription_id) WHERE i.created_at >= now() - interval '1 day' GROUP BY 1; It returns 640 year invoices worth $313,600, all since 15:25. Cause confirmed |
| 08:10 | Data Workers | Proposes the fix as a diff for the owner to merge: fct_mrr divides each year invoice by 12, and an accepted_values test on billing_interval makes the next new interval fail the run instead of the metric. With it: the blast radius, the rerun plan and the undo (revert the diff). The approval request reaches the head of data in Slack; the finance lead confirms the rule in the thread |
| 08:25 | Spellbook | The head of data approves in Spellbook; the analytics engineer merges the diff |
| 08:30 | Airflow | Data Workers queues the approved analytics_nightly rerun with trigger_airflow_dag |
| 08:55 | Aurora PostgreSQL | The run finishes. run_quality_check passes, and monitor_metrics records MRR at $1.20M: down 0.4%, as 640 accounts take the annual discount |
| 09:05 | Metabase | The transform's owner reruns mrr_daily from Data Studio |
| 09:10 | Claude, Metabase MCP server | The analytics engineer asks Claude, through the Metabase MCP server, for the MRR metric: $1.20M, matching the recorded value. Metabot now agrees. The head of data sends leadership a two-line correction before the 10:00 board prep. Data Workers writes the receipt (cause, diff, approver, rerun, checks, undo) and a graph note that fct_mrr depends on every billing_interval being normalized |
Every tool did its job; a product launch quietly changed what one column meant. Data Workers caught it before anyone opened a laptop, a named person approved the fix, and the board prep started from the right number.
| Job | What Metabase does | What Data Workers does |
|---|---|---|
| The question | Query builder, native SQL, models and Library metrics let every team ask and answer on its own | Keeps the tables and dbt models under those questions right |
| The delivery | Dashboards, subscriptions by email or Slack, embeds, Metabot in the app and in Slack | Records the headline numbers people act on and holds them to a baseline |
| The break | Runs whatever the database returns; transform tables hold their last run | Catches the jump, traces it to the change that caused it and lists every model and declared dashboard it reaches |
| The fix | Owners update questions, metrics and models, and rerun transforms | Proposes the upstream fix as a diff for its owner, routes it to a named approver and queues the approved rerun |
| The proof | Answers again from fresh data, in the dashboard, Metabot or the MCP server | Re-checks the tables, compares the recorded value and writes a receipt with cause, diff, approver and undo |
Why doesn't Metabase just do this itself?
Metabase made a sharp, sensible bet: analytics simple enough that everyone asks their own questions, open source at the core. Its guardrails fit that job. MCP tools are "all scoped to the connecting person's permissions", tool approval happens in the client, collection and data permissions decide who sees what, Pro adds row and column security and AI usage auditing, and the dependency graph in Data Studio shows which questions and dashboards rely on a table, model or metric.
All of that protects Metabase's own surface. Metabase does not run the app database, the replication task, the dbt project or the Airflow DAG, and it should not have to. Fixing this incident took a check query, a dbt change, a finance rule, a named approval, an orchestrator rerun and a verification. That is a different product with different liability: cross-system context, blast-radius scoping, approvals, rollback and receipts for changes in systems Metabase doesn't own. It is the product Data Workers is, and it builds on the Metabase your company already reads every morning.
Every tool owns a slice. Data Workers covers the whole lifecycle
Metabase owns one slice outright: letting every team ask questions and build dashboards on the warehouse, without a ticket to the data team. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, and builds on the Metabase you already run.
| Stage | Data Workers | Metabase | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 6 | Models, metrics and the Library hold curated definitions, and Data Studio is the analyst workbench for the semantic layer. Data Workers keeps one governed context graph across every platform, joined to lineage, quality and owners. |
| Analytics & Insights | 8 | 9 | Metabase's home stage: questions, dashboards, metrics, subscriptions and Metabot in the app and in Slack, open to everyone. Data Workers makes sure the tables under them are right. |
| Data Quality | 8 | 3 | Metabase shows what the database returns; it does not test the tables under a question. Data Workers checks them after every run for duplicate keys, nulls and row counts, and holds recorded values to a baseline. |
| Observability & Incidents | 8.5 | 3 | Alerts fire when a question returns a result or a time series crosses a goal line; they do not trace a cause. Data Workers traces a wrong number back to the source change, sync or model behind it, proposes the fix and verifies it. |
| Pipelines & Ingestion | 8.5 | 4 | Transforms write SQL or Python results back to the database as tables, on scheduled jobs. Data Workers queues approved reruns through the orchestrator for the pipelines under Metabase. |
| Schema & Migration | 8 | 4 | The dependency graph (Pro and Enterprise) shows what depends on a table, model or metric inside Metabase. Data Workers reviews dbt changes and scopes the blast radius across models and declared dashboards. |
| Governance & Access | 8.5 | 6 | Collection permissions, data permissions, row and column security on Pro, and per-group AI controls govern Metabase itself. Data Workers routes every data change to a named approver. |
| Security & Privacy | 8 | 5 | MCP tools are scoped to the connecting person's permissions, and AI usage auditing runs on Pro. Data Workers leaves a receipt on every data change and proposes masking for the owner to apply. |
| Cost / FinOps | 8 | 3 | Caching controls and transform tables cut repeat queries. Data Workers attributes Snowflake spend per query and per dbt model through query tags, and sums BigQuery spend for the account. |
| MLOps & Models | 7.5 | 2 | Metabase serves analytics, not models. Data Workers keeps the data under models and agents healthy. |
How Metabase and Data Workers work together
Your people stay in Metabase, Metabot, Claude or Cursor, and Slack for alerts and approval requests. Spellbook Data Catalog (in preview) is where the data team looks: each proposed fix, its blast radius, approver and rollback. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work with more than 20 specialist agents, the Autonomous Data-Conductor runs each fix end to end (detect, diagnose, fix, review, verify, remember), and per-domain guardrails hold approvals, receipts and rollback.
Where Data Workers works. Data Workers does its work natively on what sits under Metabase: Postgres, dbt and the orchestrator. Your team reaches Metabase through its MCP server in its own client. Dashboards and metrics enter the blast radius when your team records them in the context graph, along with notes such as "this metric reads a transform table". Data Workers writes nothing to Metabase and runs no transforms; BI is read by design, and Metabase's owners stay its editors.
What Data Workers checks under each dashboard. run_quality_check runs nulls, uniqueness on id columns and minimum row counts on Postgres and Snowflake tables (and BigQuery with a service-account key); get_quality_score rolls them up. monitor_metrics holds the values your team records, such as MRR, against their baseline, which is how a valid-looking change in meaning gets caught. trace_cross_platform_lineage and blast_radius_analysis follow a table back to its source and forward to every model and declared dashboard. diagnose_incident, remediate and get_incident_history run and record the incident. Your data stays in your systems: the agents, database credentials and model key run in your infrastructure, and the hosted Conductor sees workflow metadata only.
Setup over MCP today. Clone the open-source repository and add start-agent.sh entries to your client's MCP config, as the client setup docs show. The Metabase MCP server can sit next to Data Workers in the same client for your own questions; Data Workers' agents never call it. An admin turns it on under Admin > AI > MCP, and each person connects with OAuth through a Metabase consent page. Its tools come in read-only and write groups (create and update questions and dashboards, execute SQL), and an admin can switch off execute SQL instance-wide. For people who only ask questions, approve the read-only tools in your client and leave the write tools unapproved.
// Example: .cursor/mcp.json. The metabase entry is your team's own connection
// to Metabase's built-in MCP server (OAuth on first connect); Data Workers does not call it.
{
"mcpServers": {
"metabase": {
"url": "https://metabase.example.com/api/metabase-mcp"
},
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
},
"dw-quality": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-quality"]
},
"dw-incidents": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-incidents"]
}
}
}List the tools with your client's own command. An analyst can ask "is everything under the Company metrics dashboard healthy?" and get the dashboard's questions from Metabase's server and the lineage, checks and open incidents from Data Workers in one answer.
Where fixes go. Data Workers proposes the change as a diff for the owner to merge, usually a dbt model, test or source mapping, with its blast radius and undo step. It opens the pull request itself only when your team turns on the dbt GitHub pull-request target. After approval it queues the rerun through Airflow, Dagster or Prefect. Transform tables refresh on their Metabase job schedule or when the owner reruns them.
One request, L0 to L4. The autonomy ladder is set per domain.
- •L0 manual. Data Workers is connected and not acting. Someone notices a strange number and starts digging.
- •L1 observe. Data Workers checks every table under your key dashboards and logs what it would do.
- •L2 propose. Data Workers drafts the upstream fix with its blast radius. A named owner approves in Spellbook before anything runs.
- •L3 act reversibly. For proven classes, such as rerunning the nightly DAG after an approved staging fix, Data Workers acts, verifies and records the undo.
- •L4 autonomous. For a narrow class in one domain, Data Workers fixes and verifies on its own and posts the receipt.
Approvals go to a named person; a request nobody answers expires and escalates, and never grants itself. No agent can promote its own work. Read is it safe to let AI agents change production data, how approvals work for AI data agents and where does our data go for the full safety model.
If you run more than one BI tool, You're on Looker, You're on Sigma and You're on Superset and Preset show the same loop there. For the systems under this example, see You're on Postgres, You're on AWS DMS and You're on Airflow. Weighing Metabase against Superset? Our Metabase vs Superset comparison covers it.
What changes for your team
Startups on Metabase often have one or two data people serving the whole company, and most of their week goes to "is this number right?" With Data Workers, these jobs run on autopilot at the level you set.
- •Incidents. A metric that moved overnight arrives with the cause, the blast radius and a fix ready to approve.
- •Data quality. Every table under a question or model is checked after each run, and the numbers you record hold to a baseline.
- •Cloud spend. Snowflake spend is attributed down to the dbt model and BigQuery spend summed for the account, with warehouse settings drafted for the owner.
- •Access. A request for a restricted table becomes a scoped, time-boxed grant proposal the data owner approves.
- •Audits. Every data change behind a Metabase number carries the approver, the diff, the checks and the undo step.
- •Migrations. When the database under Metabase moves, say from a Postgres replica to a warehouse, tables move in approved waves with parity checks tracked per wave.
Keep Metabase, or consolidate?
Keep Metabase if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For most teams the answer is to keep Metabase: the questions, Library metrics, subscriptions and embeds belong there. What teams consolidate is the tooling around it: a separate data-quality tool, a cron script that emails when MRR moves more than 5%, and a doc listing which dashboard reads which dbt model. If you are weighing building this yourself on the Metabase MCP server and a coding agent, read build it ourselves with Claude Code and MCP servers: connecting servers is the easy part; cross-system context, approvals and rollback are the work. For what Data Workers reads and changes on each system, see Data Workers integrations.
The case for your CFO
The outcome: the numbers leadership reads in Metabase every morning, MRR, retention, pipeline, stay right, and when something upstream changes their meaning, the fix arrives before the meeting, with a named approver.
The risk story: Data Workers changes nothing in Metabase. It checks the tables and dbt models under each dashboard, proposes upstream fixes as diffs, and nothing runs until the named owner approves. Every change is verified and leaves a receipt: what broke, what changed, who approved it and how to undo it. Autonomy is set per domain from L0 manual to L4 autonomous, and an org-wide stop halts all autonomous dispatch. There is zero migration.
Why now: Metabot answers in Slack, and the MCP server puts Metabase in every AI client. A wrong table no longer waits for an analyst to spot an odd chart; it reaches the CEO as a confident sentence, and the board deck as a number.
The first win: one dashboard leadership reads, with every table under it checked after each run and its headline numbers held to a baseline. What stays the same: your Metabase questions, metrics and permissions, your Postgres and replication, your dbt project and orchestrator, and your review process. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Metabase keeps letting everyone ask their own questions; Data Workers makes sure the answers are true, and a named owner approves every fix with a receipt."
Getting started
Start with a pilot. Pick the Metabase dashboard behind a number people act on, connect Data Workers read-only to the database, dbt and the orchestrator under it, record the headline numbers you care about, and let it check every table that dashboard reads for a few weeks before turning on the first fix class. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Does Data Workers edit our Metabase questions, models or metrics? No. Questions, models, metrics, dashboards and subscriptions stay with their Metabase owners. When a definition should change, Data Workers says which one and why, and the owner edits it in Metabase.
Our checks all passed. How did Data Workers catch the wrong MRR? The rows were valid; their meaning changed. Data Workers holds the values your team records, like MRR or invoices per hour, to a baseline with monitor_metrics, so a jump that no null or uniqueness check would see still opens an incident with its lineage and blast radius.
Does Data Workers rerun our Metabase transforms or refresh persisted models? No. After an approved fix and rerun, transforms refresh on their Metabase job schedule or when the owner reruns them, and the same goes for persisted models, which Metabase now suggests converting to transforms. Data Workers re-checks the tables and records the result.
Metabot gave a wrong answer. Can Data Workers tell why? Usually Metabot was faithful to the metric and the data underneath was wrong. Data Workers' agents never call Metabot or the Metabase MCP server; they trace the metric's tables back to the source change, sync or dbt model that moved, and its receipt records the cause and the fix.
Does this work on open source Metabase? Yes. Data Workers works on the database, dbt and orchestrator under Metabase, so the plan you run does not matter. The table checks run natively on Postgres, Snowflake and BigQuery, across 50+ connectors.
Sources
- •Metabase, Releases (Metabase 63, Jul 2026; 62, Jun 2026: MCP charts, Metabase CLI; 61, May 2026: AI governance; 60, Apr 2026: official MCP server, Metabot in Slack; 59, Mar 2026: Data Studio, dependencies graph, Library), https://www.metabase.com/releases (checked Oct 3, 2026)
- •Metabase, GitHub releases (v0.63.19 and v0.58.35 on Oct 1, 2026; v0.64.0-beta on Sep 24, 2026), https://github.com/metabase/metabase/releases (checked Oct 3, 2026)
- •Metabase, MCP server (endpoint, OAuth consent, permissions, client-side tool approval, read-only and write tools), https://www.metabase.com/docs/latest/ai/mcp (checked Oct 3, 2026)
- •Metabase, Metabot (in the app and in Slack), https://www.metabase.com/docs/latest/ai/metabot (checked Oct 3, 2026)
- •Metabase, AI settings (AI usage auditing on Pro and Enterprise), https://www.metabase.com/docs/latest/ai/settings (checked Oct 3, 2026)
- •Metabase, Metrics (data source, formula, default time dimension; Library), https://www.metabase.com/docs/latest/data-modeling/metrics (checked Oct 3, 2026)
- •Metabase, Transforms (tables written to the database on scheduled jobs; Postgres supported), https://www.metabase.com/docs/latest/data-studio/transforms/transforms-overview (checked Oct 3, 2026)
- •Metabase, Model persistence ("Prefer Transforms instead of model persistence"; Postgres, MySQL, Redshift), https://www.metabase.com/docs/latest/data-modeling/model-persistence (checked Oct 3, 2026)
- •Metabase, Alerts (question returns a result; time series crosses a goal line), https://www.metabase.com/docs/latest/questions/alerts (checked Oct 3, 2026)
- •Metabase, Dashboard subscriptions (email or Slack, schedules, PDF attachments), https://www.metabase.com/docs/latest/dashboards/subscriptions (checked Oct 3, 2026)
- •Metabase, Dependency graph (Data Studio; Pro and Enterprise), https://www.metabase.com/docs/latest/data-studio/dependencies/graph (checked Oct 3, 2026)
- •Metabase, Pricing (Open Source, Starter, Pro, Enterprise plan features), https://www.metabase.com/pricing/ (checked Oct 3, 2026)
- •Data Workers, Client setup (open-source docs), https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)
- •Data Workers open-source repository, agent tools and start-agent.sh, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)