You're on SQLMesh: SQLMesh Plans and Applies Your Changes. Data Workers Runs Production Between Plans

Your team thinks in plans, environments, intervals and audits. Every change starts in a dev environment, sqlmesh plan shows exactly which models it touches and classifies each one as breaking, non-breaking or forward-only, and promotion to prod is a virtual update that swaps references instead of rebuilding tables. Incremental models process only the intervals they are missing, audits run after every evaluation, and column-level lineage comes from SQLGlot parsing every query. SQLMesh is now "a project of the Linux Foundation" with its own technical steering committee, and Tobiko Data, its original author, has been part of Fivetran since September 2025, with Tobiko Cloud still offered as the commercial product. SQLMesh is where your team plans and applies transformation changes safely. Data Workers runs production between plans: it catches what goes wrong when no code changed, diagnoses it across systems, proposes the repair and verifies the numbers, behind approvals.

Most production incidents on a SQLMesh project happen on days nobody ran a plan: the models are reviewed, the inputs changed.

Key takeaways

• •SQLMesh keeps its job. Plans, virtual data environments, change categories, audits, unit tests and the scheduler stay where your engineers use them.
• •Data Workers takes production between plans. It baselines the numbers your team names, values included, and catches runs that pass every audit on wrong inputs.
• •Clear lines in SQLMesh. Data Workers connects over the SQLMesh CLI and Python API today. It reads models, intervals and audit results; restatement plans and model changes are applied by your team in SQLMesh.
• •Reruns behind an approval. Data Workers queues approved reruns through the orchestrator that runs your pipelines, such as Dagster or Airflow, with the undo recorded first.
• •One approval, one receipt. A named owner approves in Spellbook; the receipt records the cause, the scope, the runs, the verification and the undo.

SQLMesh is where your team plans and applies changes. Data Workers runs production between plans.

SQLMesh makes every change your team ships safe and cheap. Data Workers owns whether production stays right in between. Here is a quarter-end week at a travel marketplace that takes bookings in 31 currencies, an illustration rather than a customer case. A dlt pipeline, run by a Dagster job called fx_rates_ingest, loads daily exchange rates from the rates vendor's API into Databricks at 06:15. SQLMesh runs on Databricks: fx.daily_rates and marts.fct_bookings_usd are INCREMENTAL_BY_TIME_RANGE models, marts.agg_gmv_daily builds on them, and every model carries not_null, unique_values and accepted_range audits. Finance reads GMV in USD in Lightdash and starts the Q3 close on Thursday.

Nothing in SQLMesh misbehaved. Each run evaluated its missing intervals and every audit checked what it was written to check. The rows were valid; they were Friday's. Data Workers compared the values with their own history, found the cause outside the project and handed a named owner a scoped repair two days before the close.

Why doesn't SQLMesh just do this itself?

Because SQLMesh is designed around code changes, and that focus is why teams pick it. A plan tells you what will change before anything does. A run evaluates the intervals a model is missing, deterministically, and stops there. Audits validate the model's own output after each evaluation; SQLMesh's docs are candid that a failed audit in a run stops the run while the data "is already present in the production table," because a run works directly on prod. Restating history is left to a person on purpose: a restatement plan "will trigger a cascading backfill for all selected models, as well as all models downstream from them," and that costs compute. Those are the right choices for a transformation framework.

The tooling around SQLMesh follows the same scope. Tobiko Cloud adds pipeline status, alerts, a debugger, a data catalog, cost monitoring by model on BigQuery and Snowflake, and finer change classification, all about SQLMesh's own pipelines. The CLI's prompt command uses an LLM to write a SQL query from a prompt. There is no official SQLMesh MCP server; community servers exist. None of it is meant to judge whether a vendor's rates are stale.

The quarter-end fix crossed five systems: a vendor API, an ingestion job, two SQLMesh models, a lakehouse and a finance dashboard. It needed a reload, a two-day restatement, an undo ready first, a named approver and a record finance could read. That is a different product, with liability beyond the project, and Data Workers is built for it, on top of SQLMesh.

Every tool owns a slice. Data Workers covers the whole lifecycle

SQLMesh owns safe transformation changes, and it is very good at them. Each point tool around it adds another console, another contract and another handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, with SQLMesh at the center of the transformation work.

SQLMesh leads on its home stage, as it should. For the category view, read what is an agentic data platform and how Data Workers differs from data observability.

How SQLMesh and Data Workers work together

SQLMesh stays on top, where engineers plan, review and apply changes from the CLI, the VS Code extension or a coding agent. Spellbook Data Catalog (in preview) is where the data team reviews, approves and rolls back. Data Context Wizard joins the SQLMesh project to ingestion, the lakehouse and BI in one governed context graph, the Data-Agents Swarm does the work with 20+ specialist agents, and the Autonomous Data-Conductor carries each repair from detection to verification.

Exactly what Data Workers reads, runs and writes around SQLMesh.

Data Workers never runs a plan against your environments; SQLMesh's plan review stays the gate for every change to prod. It also reviews your team's pull requests with a blast-radius comment and an impact diff that reaches past the project into dashboards. It connects to dlt, Lightdash and the rates vendor over their APIs today; dlt loads run when the Dagster job runs. For orchestration in depth, read about the orchestration agent and the incident debugging agent.

Setup in your coding agent. Every Data Workers agent is an MCP server, set up by the documented path in the client setup guide: clone the open-source repo and add one start-agent.sh entry per agent. The SQLMesh CLI runs in the same terminal under the client's command approvals. Example for Claude Desktop or Cursor:

{
  "mcpServers": {
    "dw-context-catalog": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-context-catalog"] },
    "dw-incidents": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-incidents"] },
    "dw-quality": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-quality"] },
    "dw-connectors": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-connectors"] }
  }
}

Ask "why is Monday's GMV high, and what would fix it?" and Data Workers returns the frozen rates, the vendor fault, every model and dashboard downstream and a proposed reload and restatement waiting for its approver. For a shared endpoint, the Data Workers remote server serves /mcp with an API key (bearer) or OAuth tokens from your identity provider, verified through JWKS. Our Claude Code with SQLMesh guide covers the coding side.

One SQLMesh incident, L0 to L4. The same week at each level of the autonomy ladder, set per domain.

• •L0 manual. Finance spots high GMV on Thursday; an engineer finds the stale rates and works out the restatement by hand.
• •L1 observe. Data Workers posts the diagnosis Tuesday morning: frozen rates, the vendor cause, both models and both dashboards downstream. Nothing changes.
• •L2 propose. Data Workers proposes the reload, the restatement scope, the undo and the new audit. Nothing runs until the finance data owner approves.
• •L3 act reversibly. For change classes with a proven record, such as reloading one ingestion job for named days with prior table versions recorded, Data Workers queues the run, verifies it and writes the receipt.
• •L4 autonomous. For a scoped domain with a long clean record, Data Workers handles the repeatable steps end to end; restatement plans and model changes still go through your team in SQLMesh.

For the safety model, read is it safe to let AI agents change production data, how approvals work and autonomy levels L0 to L4. On where data lives: the agents run in your infrastructure and hold the lakehouse and orchestrator credentials, your data stays in your systems, and the hosted Conductor sees workflow metadata only.

What changes for your team

SQLMesh gave your team safe, cheap changes. Data Workers gives them an operator for production between those changes.

• •Incidents. A wrong number in a SQLMesh model gets a cross-system diagnosis, a blast radius past the project and a repair proposal, before finance opens the dashboard.
• •Data quality. Baselines on the values your team cares about join your audits, so a green run on bad inputs is caught.
• •Cloud spend. Restatements are scoped to the intervals that need them instead of a wide rebuild, and warehouse settings reach their owners drafted.
• •Access. A request for the tables SQLMesh builds becomes a scoped, time-boxed grant the data owner approves.
• •Audits. Every reload, restatement and model change carries a receipt: the cause, the scope, the approver, the verification and the undo.
• •Migrations. A move to a new warehouse runs in approved waves, with parity checks planned and tracked for each wave and a completion gate the owner signs.

The on-call engineer changes most: a restatement arrives as one proposal with its scope, evidence and undo, not a 7 a.m. judgment call. On who answers for each agent, read who owns the agents.

Keep SQLMesh, or consolidate?

Keep SQLMesh if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.

For SQLMesh, keeping it is the norm: your plans, environments and audits are how your team ships safely, and Data Workers builds on them. What teams consolidate is the tooling around it: a monitor that only sees the lakehouse, alerts across three consoles, restatement commands in a wiki. With Tobiko part of Fivetran and Fivetran merged with dbt Labs since June 2026, many teams also want an operating layer that stays neutral to those choices. The same pattern runs through you're on dbt, you're on Dagster and you're on Datafold. Building the operator yourself with a coding agent and the SQLMesh CLI? Read build it ourselves with Claude Code and MCP servers. Every connection Data Workers makes is listed on Data Workers integrations.

The case for your CFO

The outcome: the numbers your company closes the quarter on, GMV, revenue, margins, come out of SQLMesh models. Data Workers keeps those models right between releases and turns each problem into a scoped repair with an approval, not a correction after the close.

The risk story: at L1 Data Workers only reads; at L2 it changes nothing until a named person approves; at L3 it acts only on changes it can undo, such as a reload with the prior table versions recorded. Restatements and model changes always go through your team in SQLMesh. An unanswered request expires and escalates, never auto-grants. No agent can promote its own work. An org-wide stop halts all autonomous dispatch. Zero migration: SQLMesh, Dagster, Databricks, dlt and Lightdash stay put.

Why now: SQLMesh already makes code changes safe, which moves the costly incidents to days when no code changed. Those land in quarter-end numbers unless someone checks the values themselves. The first win is read-only: the metrics behind one domain, such as revenue or GMV, get baselines and a diagnosis on every anomaly. Your models, plans, CI and schedules stay the same. For the numbers, see the ROI of agentic data operations.

The sentence to repeat upstairs: "SQLMesh makes every change we ship safe; Data Workers keeps production right between changes, fixes it with an owner's approval and shows us the receipt."

Getting started

Start with a pilot. Pick one domain where a wrong number costs real money, such as the models behind GMV, connect Data Workers to the SQLMesh project, the lakehouse and the orchestrator, and run at L1 so every anomaly gets a diagnosis, a blast radius and a proposed repair. Then turn on the first write class at L2, such as approved reruns of named ingestion jobs. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.

FAQ

How does Data Workers connect to SQLMesh? Over the SQLMesh CLI and Python API today, with read access to the project and its state. It reads the tables SQLMesh builds through native connections to Databricks, Snowflake, BigQuery and PostgreSQL.

Does Data Workers run SQLMesh plans? No. Data Workers proposes the exact restatement scope and any model change as a diff; your engineers review and apply the plan in SQLMesh, and the plan review stays the gate for prod. What Data Workers runs is approved reruns through your orchestrator, such as Dagster or Airflow.

We already have audits. What does Data Workers add? Audits check a model's output against rules your team writes, and they are the right first line. Data Workers baselines the metrics your team names against their own history, so it catches inputs that are valid but wrong, like rates that stopped moving, and traces the cause outside the project.

Does Fivetran's ownership of Tobiko change anything? Not for Data Workers. SQLMesh is a Linux Foundation project under its own technical steering committee, Tobiko Cloud is still offered, and Data Workers works with it through its open CLI and API, whichever ingestion tool and orchestrator you run.

What about restatement cost? A restatement cascades to every downstream model, so scope matters. Data Workers proposes the narrowest interval range the evidence supports and lists every model it will backfill before the engineer applies the plan.

Do dev environments get affected? A restatement against prod clears the model's intervals from state in every other environment, per SQLMesh's docs. Data Workers notes which environments will reprocess in the proposal.

Sources

• •SQLMesh repository README ("a project of the Linux Foundation"; virtual data environments, plans, audits, unit tests, column-level lineage; Apache 2.0), https://github.com/SQLMesh/sqlmesh (checked Oct 3, 2026)
• •SQLMesh GOVERNANCE.md (Series of LF Projects, LLC; first TSC meeting March 10, 2026), https://github.com/SQLMesh/sqlmesh/blob/main/GOVERNANCE.md (checked Oct 3, 2026)
• •PyPI, sqlmesh 0.236.2 (Sep 8, 2026), https://pypi.org/project/sqlmesh/ (checked Oct 3, 2026)
• •Tobiko Data homepage ("Tobiko Data is now part of Fivetran"; Tobiko Cloud), https://www.tobikodata.com/ (checked Oct 3, 2026)
• •Fivetran press, "Fivetran Acquires Tobiko Data" (Sep 3, 2025), https://www.fivetran.com/press/fivetran-acquires-tobiko-data-to-power-the-next-generation-of-advanced-ai-ready-data-transformation (checked Oct 3, 2026)
• •SQLMesh docs, Plans (change categories, restatement plans, virtual updates), https://sqlmesh.readthedocs.io/en/stable/concepts/plans/ (checked Oct 3, 2026)
• •SQLMesh docs, Environments, https://sqlmesh.readthedocs.io/en/stable/concepts/environments/ (checked Oct 3, 2026)
• •SQLMesh docs, Model kinds (INCREMENTAL_BY_TIME_RANGE, missing intervals, lookback), https://sqlmesh.readthedocs.io/en/stable/concepts/models/model_kinds/ (checked Oct 3, 2026)
• •SQLMesh docs, Audits (blocking by default; plan vs run behavior; built-in audits), https://sqlmesh.readthedocs.io/en/stable/concepts/audits/ (checked Oct 3, 2026)
• •SQLMesh docs, CLI reference (plan --restate-model, run, table_diff, prompt), https://sqlmesh.readthedocs.io/en/stable/reference/cli/ (checked Oct 3, 2026)
• •SQLMesh docs, Tobiko Cloud overview (monitoring, alerts, debugger, data catalog, cost by model on BigQuery and Snowflake), https://sqlmesh.readthedocs.io/en/stable/cloud/cloud_index/ (checked Oct 3, 2026)
• •Fivetran press, "Fivetran + dbt Labs Complete Merger" (Jun 1, 2026), https://www.fivetran.com/press (checked Oct 3, 2026)
• •SQLMesh docs, Browser UI guide ("Browser UI is deprecated. Please use the VSCode extension instead."), https://sqlmesh.readthedocs.io/en/stable/guides/ui/ (checked Oct 3, 2026)
• •Databricks docs, Delta table history and RESTORE, https://docs.databricks.com/aws/en/delta/history (checked Oct 3, 2026)
• •Data Workers open-source repository, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)
• •Data Workers client setup guide, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)