You're on Fivetran: Fivetran Moves the Data In. Data Workers Owns Whether What Landed Is Right
Fivetran moves the data in from 900+ sources. Data Workers owns whether what landed is right: checks, diagnosis and fixes across dbt and Activations, behind approvals.
Your team thinks in connections, syncs, schema change handling and Monthly Active Rows. Every replicated table carries _fivetran_synced and _fivetran_deleted, and a sync that finishes means every change arrived without loss. Since June 1, 2026, Fivetran and dbt Labs are one company, so the dbt project that turns raw tables into marts comes from the same vendor, and Census now ships inside Fivetran as Activations, sending warehouse data back out to the tools your customer teams use. Fivetran moves the data in. Data Workers owns whether what landed is right: it checks landed tables, diagnoses what a successful sync broke downstream, proposes the fix to a named owner and verifies the number, behind approvals.
Key takeaways
- •Fivetran keeps its job. Connections, syncs, schema change handling, HVR replication, Transformations and Activations stay with the team that runs them today.
- •Data Workers owns what lands. It checks landed tables for duplicates, nulls and volume on Snowflake and BigQuery, and baselines the metrics your team names.
- •It sees past the sync. One context graph joins Fivetran's tables to the dbt models, dashboards and Activations syncs that read them, so the reach of a change is known before the next job runs.
- •Fivetran stays in your team's hands. Data Workers connects to Fivetran over its REST API or official MCP server today. It proposes pauses and re-syncs with the reason attached; your team runs them in Fivetran.
- •One approval, one receipt. A named owner approves in Spellbook, and the receipt records the cause, the fix, the approver, the checks and the undo.
Fivetran moves the data in. Data Workers owns whether what landed is right.
Here is a Tuesday night at a B2B software company, an illustration rather than a customer case. A billing application runs on SQL Server, and the sqlserver_billing connection replicates it into BigQuery twice an hour over change tracking. A hand-written dbt staging model, stg_billing__contract_lines, selects from the raw table; fct_contract_arr builds on it in the dbt platform job nightly_finance at 02:00. An Activations sync, "Account ARR to Gainsight", is triggered when that job completes and updates the Company object that customer success plans renewals from. Data Workers runs at L2 propose for the finance domain.
| Time | System | What happens |
|---|---|---|
| 23:05 | SQL Server | The vendor's upgrade script rebuilds contract_lines: it deletes all 48,210 rows and re-inserts them with new line_id values. The business key, line_key, is unchanged |
| 23:30 | Fivetran | The sync replicates every change faithfully: the old rows get _fivetran_deleted = TRUE, 48,210 new rows arrive, and the sync succeeds. No schema changed |
| 23:41 | Data Workers and BigQuery | The scheduled post-sync checks run. run_quality_check flags volume at twice its baseline and line_key no longer unique |
| 23:48 | Data Workers | diagnose_incident classifies a source-side reload, not a column change; half the rows carry Fivetran's deleted flag. trace_cross_platform_lineage and blast_radius_analysis map the reach: the staging model doesn't filter _fivetran_deleted, so fct_contract_arr, the Sigma ARR workbook and the Gainsight sync would all carry doubled ARR |
| 23:52 | PagerDuty and Spellbook | Data Workers raises a PagerDuty incident for the analytics on-call with one proposal: hold the Gainsight sync; add where not _fivetran_deleted to the staging model as a diff; add a dbt unique test on line_key |
| 00:20 | Fivetran Activations | The on-call engineer switches "Account ARR to Gainsight" to Manual, so the 02:00 job won't trigger it |
| 00:35 | Spellbook and GitHub | The engineer approves; their coding agent opens the pull request from the approved diff, Data Workers posts the blast radius on it, dbt CI passes and the engineer merges at 01:05 |
| 02:00 | dbt platform | nightly_finance builds on the fixed model; the new test passes |
| 02:25 | Data Workers and BigQuery | Data Workers re-runs the uniqueness and volume checks, compares total ARR with the baseline the team records with monitor_metrics, finds it within normal movement and writes the receipt |
| 08:10 | Activations and Gainsight | The RevOps owner reads the receipt and restores the sync's trigger; Gainsight updates with the right values |
Nothing in Fivetran misbehaved: soft deletes are how it keeps history. The problem lived one step later, in a staging model written before anyone imagined a full table rebuild. Data Workers saw the landed table, the dbt project and the Activations sync as one chain and put the decision in front of a person before 02:00.
| Job | What Fivetran does | What Data Workers does |
|---|---|---|
| Moving data in | Managed connections, incremental syncs, retries, schema change handling, HVR | Leaves syncs with your team and checks what each one landed |
| Keeping history | _fivetran_deleted and _fivetran_synced record every change | Treats a jump in flagged rows as evidence, so a purge reads as a purge |
| Transforming | dbt, now from the same vendor, builds models and runs tests | Traces each landed table through the dbt manifest and proposes model fixes as diffs for the owner to merge |
| Sending data out | Activations syncs datasets and audiences to SaaS tools | Maps which syncs read a broken model and proposes the hold, with the reason |
| The record | Sync status, webhooks and logs per connection | A receipt: cause, fix, approver, checks and undo, in Spellbook and the audit trail |
Why doesn't Fivetran just do this itself?
Because Fivetran's promise is faithful replication, and that promise is why teams trust it. When a source deletes a row, Fivetran flags it instead of removing it, so history survives. When a source rebuilds a table, the sync replays every delete and insert in order. A replication tool that guessed which source changes were mistakes and refused to land them would be a worse replication tool.
Fivetran's newer products keep the same sensible scope. The Fivetran Context Layer, announced in private beta on September 16, 2026 and now in public preview in Fivetran's docs, gives agents data and metadata through Agents Schema, an open standard stored in the warehouse. dbt Wizard, in public preview, works inside the dbt project. Activations sends what the warehouse holds. The official Fivetran MCP server runs with read scope by default, and its README states that write and delete confirmations are advisory: the server does not enforce them.
The Tuesday fix crossed six systems: a billing database, a Fivetran connection, a BigQuery table, a dbt project, an Activations sync and Gainsight. It needed checks on what landed, a blast radius past the dbt project, a hold only the sync's owner should press, a named approver and a receipt. Taking on liability for changes across tools Fivetran doesn't run is a different product category. That product is Data Workers, and it builds on Fivetran.
Every tool owns a slice. Data Workers covers the whole lifecycle
Fivetran owns moving data in, and it is very good at it. 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 Fivetran at the front of the pipeline.
| Stage | Data Workers | Fivetran | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | Fivetran knows every connection, table and column it lands, and the Context Layer (public preview) adds metadata for agents. Data Workers keeps one governed context graph across Fivetran, dbt, the warehouse and every consumer, with owners and usage. |
| Analytics & Insights | 8 | 2 | Fivetran lands the tables analysts query; dbt Charts (public beta) and Wizard Explore Mode (public preview) sit on the dbt side. Data Workers answers data questions from governed definitions with lineage behind every number. |
| Data Quality | 8 | 4 | Fivetran guarantees complete, lossless delivery, and now stewards GX Core. Data Workers checks what landed for nulls, duplicates and volume, and baselines the metrics your team names. |
| Observability & Incidents | 8.5 | 5 | Sync status, alerts, webhooks and a log of every sync event. Data Workers diagnoses the incident across systems, including syncs that succeeded and still broke a number. |
| Pipelines & Ingestion | 8.5 | 9 | Fivetran's home stage: managed connections, incremental syncs, schema change handling, HVR replication, Activations out to SaaS tools. Data Workers leaves syncs with your team and fixes what they feed. |
| Schema & Migration | 8 | 5 | Schema change handling settles what arrives, and type changes are promoted losslessly. Data Workers classifies each schema change in the dbt manifest as breaking or safe, traces it, and plans migrations in approved waves. |
| Governance & Access | 8.5 | 5 | Role-based access to connections and destinations inside Fivetran. Data Workers drafts each warehouse access request as a scoped grant with an expiry for a named owner to approve. |
| Security & Privacy | 8 | 6 | Column blocking and hashing, Hybrid Deployment and strong controls for data in motion. Data Workers' pull request review flags new columns whose names or annotations look sensitive, and leaves a receipt on every data change. |
| Cost / FinOps | 8 | 4 | MAR pricing makes the bill predictable at the connection level. Data Workers attributes Snowflake credits to the dbt models behind them and drafts the fix for the owner. |
| MLOps & Models | 7.5 | 2 | Fivetran can land feature sources but does not watch models. Data Workers keeps the data under your models fresh and correct. |
Fivetran 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 Fivetran and Data Workers work together
Admins keep running connections in the Fivetran dashboard, or from a coding agent holding Fivetran's MCP server. Spellbook Data Catalog (in preview) is where the data team reviews, approves and rolls back. Data Context Wizard joins Fivetran's landed tables to the dbt project, BI and outbound syncs in one governed context graph, the Data-Agents Swarm does the work with 20+ specialist agents, and the Autonomous Data-Conductor carries each fix from detection to verification.
| What it covers | How | |
|---|---|---|
| Reads | The tables Fivetran lands, with their system columns | Native connections to Snowflake, BigQuery, Databricks and PostgreSQL |
| Reads | The dbt manifest, models and lineage built on each landed table | Native dbt connection |
| Reads | Connections, sync times and schema config in Fivetran's own terms; Activations syncs | Fivetran's REST API or official MCP server in the same client session; the Activations API |
| Runs | Checks after each sync, and approved reruns of the dbt jobs your team names | run_quality_check on the warehouse; reruns queued through your orchestrator, or by the owner in the dbt platform |
| Proposes | Model fixes, tests, sync holds and re-syncs | A diff for the owner to merge; holds and re-syncs with their reason, for your team to run in Fivetran |
Data Workers leaves syncs, schema change handling, column blocking and hashing, Activations and your MAR with your team, by design. It reviews your team's dbt pull requests with a blast-radius comment that reaches past the project into dashboards and outbound syncs, and connects to Gainsight and Sigma over their APIs today. The schema-change wiring is covered step by step in Data Workers + Fivetran, and Fivetran custom connectors with Claude Code covers the coding side.
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. Fivetran's MCP server goes in the same file, following its README, with read scope. Example for Claude Desktop or Cursor:
{
"mcpServers": {
"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"] },
"dw-context-catalog": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-context-catalog"] },
"dw-schema": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-schema"] }
}
}Ask "what did last night's syncs change, and is anything downstream wrong?" and Data Workers returns each flagged table, its likely cause and reach, and any waiting proposal. List the tools with your client's own command, such as /mcp. 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.
One Fivetran incident, L0 to L4, set per domain.
- •L0 manual. A customer success manager asks at 09:00 why an account's ARR doubled; an engineer finds the soft-deleted rows by afternoon.
- •L1 observe. Data Workers posts the diagnosis at 23:48: the reload, the missing filter and everything downstream. Nothing changes.
- •L2 propose. Data Workers proposes the hold, the staging diff and the test. Nothing changes until the on-call engineer approves and acts.
- •L3 act reversibly. For change classes with a proven record, such as queuing the rerun of a named dbt job through your orchestrator after an approved fix merges, Data Workers runs the step, 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; Fivetran syncs, Activations syncs and model merges stay with your team.
For the safety model, read is it safe to let AI agents change production data and how approvals work. On where data lives: the agents run in your infrastructure and hold the warehouse credentials and model key, your data stays in your systems, and the hosted Conductor sees workflow metadata only.
What changes for your team
Fivetran took extraction code off your team's plate. Data Workers takes the next job: making sure what lands is right before anything builds on it.
- •Incidents. A sync that succeeded and still broke a number gets a cross-system diagnosis and a fix proposal before the morning standup.
- •Data quality. Landed tables on the connections you choose are checked for duplicates, nulls and volume after each sync.
- •Cloud spend. Snowflake credits are traced to the dbt models behind them, and fixes reach their owners drafted.
- •Access. A request for the tables Fivetran lands becomes a scoped, time-boxed grant the data owner approves.
- •Audits. Every fix to what Fivetran feeds carries a receipt: cause, change, approver, checks and undo.
- •Migrations. A move to a new warehouse runs in approved waves, with parity checks planned and tracked per wave and a completion gate the owner signs.
The on-call engineer changes most: a midnight decision arrives as one proposal with its evidence and its undo. On accountability, read who owns the agents.
Keep Fivetran, or consolidate?
Keep Fivetran if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For Fivetran, keeping it is the norm: Data Workers doesn't move data, and your connections are where ingestion lives. What teams consolidate is the checking around it: a monitor that only sees the warehouse, alert rules in three consoles, a soft-delete runbook nobody reads. With Fivetran, dbt Labs, SQLMesh and Census under one roof, many teams also want an operating layer that stays neutral to those choices and covers the warehouse, orchestrator, BI and every outbound sync the same way. The same pattern runs through you're on dbt, you're on SQLMesh and you're on Airbyte; the outbound side is in you're on Census. Comparing ingestion tools? Read Airbyte vs Fivetran. Building the checks yourself? Read build it ourselves. For the leadership view, read the Fivetran data leaders guide.
The case for your CFO
The outcome: the numbers your customer teams act on, ARR, renewals and usage, start as rows Fivetran lands. Data Workers makes sure those rows are right before dbt builds on them and before Activations sends them anywhere, so a source-side change becomes a scoped fix at midnight instead of a correction after a customer call.
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 steps it can undo. Fivetran syncs, Activations syncs and schema settings stay with your team. An unanswered request expires and escalates, never auto-grants. No agent can promote its own work, and an org-wide stop halts all autonomous dispatch. Zero migration: Fivetran, dbt, BigQuery, Sigma and Gainsight stay put.
Why now: one vendor now runs ingestion, transformation and activation, and agents are arriving on every side of it, from the Fivetran MCP server to dbt Wizard. A wrong row can travel from source to warehouse to a SaaS tool in one night. You want one approval flow and one audit trail across all of it. For the numbers, see the ROI of agentic data operations.
The first win is read-only: checks on the landed tables of one production connection, plus the dbt models and Activations syncs it feeds. What stays the same: your connections, dbt project, CI, schedules and BI.
The sentence to repeat upstairs: "Fivetran moves our data in; Data Workers makes sure what lands is right before anyone builds on it or sends it out, and shows us the receipt."
Getting started
Start with a pilot. Pick the Fivetran connection whose data reaches money, usually the billing or product database, connect Data Workers read-only to the tables it lands, the dbt project and the Activations syncs downstream, and run at L1 so every flagged table gets a diagnosis, a blast radius and a proposed fix. Then move that domain to L2 so fixes arrive in Spellbook for a named owner. 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 Fivetran? Over Fivetran's REST API or its official MCP server today, for connections, sync times and schema config. The heavy lifting runs where Fivetran lands data: native reads of Snowflake, BigQuery, Databricks or PostgreSQL, and of the dbt project.
Does Data Workers trigger or pause Fivetran syncs? No. Connection syncs, re-syncs and Activations syncs stay with your team. Data Workers proposes a pause, hold or re-sync with the reason and the tables involved, and your team runs it in Fivetran.
How does it handle `_fivetran_deleted` and soft deletes? Fivetran flags a deleted source row with _fivetran_deleted = TRUE instead of removing it. Data Workers treats a jump in flagged rows next to duplicate keys as a reload signal, and where the dbt manifest shows a model ignoring the flag, it proposes the filter and a test as a diff for the owner to merge.
Fivetran, dbt Labs, SQLMesh and Census are one company now. Does that matter? Data Workers reads each through its own interfaces, as before. The consolidation makes a neutral operating layer more useful, since your approvals, receipts and context graph also cover the warehouse, orchestrator, BI and tools outside the vendor's stack.
How is this different from the Fivetran Context Layer? The Context Layer, in public preview, gives agents data and metadata through Agents Schema. Data Workers acts on context: it checks what landed, diagnoses incidents across systems and gets fixes approved and verified, with a receipt.
Can we run it read-only? Yes. Start with read access to the landed tables and the dbt manifest, and Fivetran's MCP server at its default read scope. Move a domain to L2 when the diagnoses have earned it.
Sources
- •Fivetran homepage ("The data foundation for AI"; "Automated data for autonomous agents"; 900+ sources and destinations), https://www.fivetran.com/ (checked Oct 3, 2026)
- •Fivetran press, "Fivetran + dbt Labs Complete Merger" (Jun 1, 2026; announced Oct 13, 2025), https://www.fivetran.com/press/fivetran-dbt-labs-complete-merger-to-create-the-data-infrastructure-for-trusted-ai-agents (checked Oct 3, 2026)
- •Fivetran press, dbt Summit 2026 (Sep 16, 2026: dbt v2 and dbt State GA; dbt Wizard and Wizard Explore Mode public preview; dbt Charts and Wizard CLI public beta; Fivetran Context Layer private beta, built on Agents Schema), https://www.fivetran.com/press/fivetran-dbt-labs-announces-new-capabilities-to-make-enterprise-data-agent-ready-at-dbt-summit-2026 (checked Oct 3, 2026)
- •Fivetran press, "Fivetran Acquires Tobiko Data" (SQLMesh and SQLGlot; 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)
- •Fivetran press, steward of GX Core (May 13, 2026), https://www.fivetran.com/press/fivetran-to-become-steward-of-the-great-expectations-open-source-community-and-gx-core-project (checked Oct 3, 2026)
- •Fivetran blog, "Introducing Activations" ("the result of the integration of Census into Fivetran"; Feb 2, 2026), https://www.fivetran.com/blog/introducing-activations-bridging-the-gap-between-data-and-action (checked Oct 3, 2026)
- •Fivetran docs, Activations (datasets, syncs, Audience Hub), https://fivetran.com/docs/activations (checked Oct 3, 2026)
- •Fivetran docs, Activations triggering syncs (schedules, set to Manual to remove a schedule, dbt Cloud run completion, upstream Fivetran connections, API), https://fivetran.com/docs/activations/syncs/triggering-syncs (checked Oct 3, 2026)
- •Fivetran docs, Census Migration FAQ ("Census joined Fivetran"; month-to-month Census plans ended March 2026; MAR), https://fivetran.com/docs/activations/census-migration-faq (checked Oct 3, 2026)
- •Fivetran docs, Activations Gainsight destination (Company object), https://fivetran.com/docs/activations/destinations/gainsight (checked Oct 3, 2026)
- •Fivetran docs, SQL Server connector (
_fivetran_deleted,_fivetran_synced,_fivetran_id; "A DELETE in the source table updates the corresponding row in the destination with_fivetran_deleted = TRUE"; change tracking and CDC), https://fivetran.com/docs/connectors/databases/sql-server (checked Oct 3, 2026) - •Fivetran MCP server README (read scope by default;
FIVETRAN_SCOPE;DISALLOWED_ACTIONS; confirmations advisory, not enforced; latest tag 0.5.1, Sep 30, 2026; no Activations tools), https://github.com/fivetran/fivetran-mcp (checked Oct 3, 2026) - •Fivetran pricing (Monthly Active Rows), https://fivetran.com/pricing (checked Oct 2, 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)