You're on SELECT: SELECT Tells You Which dbt Model Costs What. Data Workers Makes Sure the Cheaper Version Still Returns the Right Rows

Your data platform team runs on SELECT. Visibility shows where each Snowflake credit goes, by warehouse, user, dbt model and Looker Explore. Usage Groups split spend across teams with budgets, Monitors alert when a workload jumps, and Insights land in an owner's queue with an effort estimate, a status and, since April 2026, a Jira issue created straight from the Insight. Automated Savings adjusts warehouse settings continuously, and you can switch it off per warehouse. SELECT for Databricks is available, BigQuery is in Early Access, and since September 30, 2026 every cost and usage dataset behind the app is on the v2 API, with an MCP server listed as coming soon. SELECT finds and cuts the spend. Data Workers owns whether the data those warehouses compute is still right after the cut: it attributes Snowflake credits to the dbt models behind them, checks the cheaper version, traces who reads it and sends each fix to its owner, behind approvals.

The two jobs meet every time a costly model gets cheaper.

Key takeaways

• •SELECT keeps its job. Cost visibility, Insights, Monitors, Usage Groups, budgets and Automated Savings stay with your platform team. Data Workers works with SELECT from day one.
• •Data Workers checks what the saving did to the data. After a cost change ships, it checks keys, nulls and row counts in Snowflake, compares the metrics your team baselines and reads the dbt manifest to see what changed.
• •It traces the readers before anyone touches the fix. Lineage from the dbt manifest and notes in the context graph show which marts, notebooks and syncs read the model.
• •Fixes go to owners, behind approvals. The model change is drafted as a diff for the model owner; the rebuild is queued through your orchestrator after a named person approves.
• •Every fix leaves a receipt with the checks, the diff and the approver, and Data Workers traces the model's Snowflake credits before and after through dbt query tags, so the saving and the correctness sit side by side.
• •Start with a pilot on one domain, read-only first, and climb from L0 manual toward L4 autonomous.

SELECT tells you which dbt model costs what. Data Workers makes sure the cheaper version still returns the right rows.

SELECT answers which workload costs what and what to change to spend less. Data Workers answers whether the change kept the numbers right, who reads them and who signs off on the fix. Most cost changes on a dbt project are data changes: a materialization, an incremental filter, a schedule. When one changes the rows, the cost chart improves and the revenue chart moves with it.

Here is a Monday at a subscription software company. Chargebee subscription events land in Snowflake through Airbyte. A dbt Core project, run nightly by a Prefect flow, builds fct_subscription_mrr as a full table rebuild over three years of events. It feeds mrt_arr_by_segment, which a Hex app turns into the board metrics, and a Census sync that writes account MRR to HubSpot at 07:00. The team has recorded both readers as notes in the Data Workers context graph and baselines daily MRR with monitor_metrics. This is an illustrative example.

Nothing in SELECT was wrong: it found the costliest model, routed it to the right owner, and the saving was real. Append suits an event table; this model held one row per subscription. The gap sat between the cost decision and the data: no check on the key, no view of who read the mart, no named sign-off on a change to a revenue number. Data Workers checked the key, traced the readers, drafted a fix that kept most of the saving, and put the credits next to the checks.

Why doesn't SELECT just do this itself?

Because SELECT is built to answer one question extremely well: where the credits go and how to spend fewer of them. It reads warehouse metadata and query history, decodes dbt and BI query tags, and acts on the one thing a cost tool can safely own, warehouse settings, with a switch per warehouse and a log of every action. Its AI summarises queries and proposes fixes from sanitized query text and performance metrics, by its own published policy. Its Insights end in an owner's queue or a Jira issue. That restraint is a good product decision: a cost tool that rewrote dbt models would carry the liability for every number those models feed.

Knowing that fct_subscription_mrr holds one row per subscription, that a Hex board app and a HubSpot sync read it, and that a merge on the key keeps most of the saving, is data-engineering knowledge. Acting on it crosses the warehouse, dbt, the orchestrator and BI, each owned by someone else. A cost tool is measured on credits saved; the data team is measured on the number being right. Data Workers is the product built for the second job, on top of the cost tool you already run.

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

SELECT owns its slice: data cloud cost observability and automated savings. 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 cost view SELECT already gives you.

How SELECT and Data Workers work together

Your people stay in Claude Code, Cursor or Claude, in SELECT and in Snowflake. Spellbook Data Catalog (in preview) is where the data team reviews each finding, diff, approver and rollback, with approval requests in Slack or email. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm (20+ specialist agents) does the work, and the Autonomous Data-Conductor runs each fix end to end behind per-domain guardrails.

What SELECT keeps. The cost view, Insights, Monitors, Usage Groups, budgets and Automated Savings. Data Workers connects to SELECT over its API today, and your team's own assistant can call SELECT's v2 API (and use its MCP server once SELECT ships it) side by side with Data Workers' MCP servers, so an engineer can ask SELECT what a model costs and Data Workers what reads it in one session. Data Workers' agents don't call SELECT's MCP server; their checks rest on what Data Workers reads itself.

What Data Workers reads. With your Snowflake credentials, Data Workers reads warehouse metering and per-query attribution from Snowflake's own usage views, over the window you ask for, and decodes the dbt node, project and run from the query tag, which SELECT's open-source dbt-snowflake-monitoring package can set. Where query tags are set, credits trace to the dbt model; on BigQuery it sums recent job bytes into an account-level total, and it reads AWS Cost Explorer by service with its forecast. Each Data Workers action's model cost is computed from its tokens. Around the bill it reads natively what the fix needs: the dbt manifest, Snowflake checks through run_quality_check, metrics your team baselines with monitor_metrics, orchestrator runs on Airflow, Dagster, Prefect and ADF, and pull requests on GitHub, among 50+ connectors. Agents get one governed view through explain_table, trace_cross_platform_lineage and blast_radius_analysis.

What Data Workers changes, and where. Model changes are drafted as diffs for the model owner to merge. Reruns and rebuilds are queued through your orchestrator after a named person approves. Warehouse settings a fix needs are drafted for the platform owner to apply; Automated Savings keeps tuning the rest. Deletes and cleanups of tables or rows are always the owner's.

Setup for the open-source agents. The public agents come from the open-source repository: clone it and add start-agent.sh entries to your client config, as the client setup docs show.

// Example: .mcp.json for Claude Code
{
  "mcpServers": {
    "dw-quality": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-quality"]
    },
    "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"]
    }
  }
}

List the tools with your client's own command (/mcp in Claude Code), then ask "SELECT says fct_subscription_mrr is our most expensive model. What reads it, and what would a cheaper materialization change?"

One cost change, L0 to L4. The autonomy ladder is set per domain, so finance models can sit at a different level from marketing models.

• •L0 manual. Someone ships the cheaper model and hopes someone notices if the number moves.
• •L1 observe. Data Workers checks each model after a cost change ships, reports failures with the lineage behind them, and logs what each action would have needed.
• •L2 propose. It drafts the model fix and the rebuild for the owner. The owner approves before anything runs.
• •L3 act reversibly. For proven change classes, such as queuing the rebuild of a model whose approved fix has merged, it queues the step, re-checks and records. The model owner can revert the change at any point.
• •L4 autonomous. For a scoped, trusted class in one domain, it runs the loop end to end and posts the receipt. Spend decisions and SELECT settings stay with your platform team.

More on safety, approvals, who owns the agents, autonomy levels, where your data goes, integrations, Data Workers on Snowflake and the Cost Savings & Data Cleanup agent. The same pattern holds for Keebo, and the dbt side is on You're on dbt and You're on Prefect.

What changes for your team

Platform teams on SELECT lose time at the seam between saving and trusting: the Insight nobody picks up because nobody can say what it will break, the cheaper model that moved a revenue number, the question of who approved it. With Data Workers, those jobs run on autopilot at the level you set.

• •Cloud spend. Snowflake credits are traced to the dbt model behind them through query tags, around every fix.
• •Data quality. Keys, nulls and row counts are checked after each cost change ships, and failures go to the cause.
• •Incidents. A saving that breaks a number arrives traced, with its owner named and the fix drafted.
• •Migrations. When a platform moves, each wave is planned with its checks, and the owner signs off before it closes.
• •Audits. Each fix links the approver and the checks, with the model's credits before and after.
• •Access. Grants a fix needs are dry-run first and approved by a named owner.

Analytics engineers clear more of the Insights queue, because each change comes back checked. The FinOps lead guide and the guide for heads of data cover the leader's side.

Keep SELECT, or consolidate?

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

SELECT stays your view of the bill; nothing here replaces its Insights or Automated Savings. What teams consolidate is the glue around it: the Insights nobody dares to ship, the ad hoc queries that check a model after someone made it cheaper, and the Slack threads that reconstruct who approved a change. Building it yourself? Calling an MCP server is the easy part; the checks, lineage, approvals and receipts are the work. See also alternatives to select.dev for Snowflake cost, how to optimize Snowflake costs and Snowflake cost optimization with AI agents.

The case for your CFO

The outcome: every Snowflake saving your team ships comes with proof that the numbers it feeds are still right, and with the credits it saved, per model. You cut spend without risking the revenue report.

The risk story is plain. Data Workers changes nothing in SELECT and runs no warehouse changes. It reads Snowflake metering and query attribution, checks the data, traces the readers and drafts each fix for a named owner to approve. Unanswered requests expire and escalate; they never auto-grant. No agent can promote its own work. Autonomy is set per domain from L0 manual to L4 autonomous, an org-wide stop halts all autonomous dispatch, and the admin kill switch takes two people and revokes the tenant's keys, tokens and sessions. The agents run in your infrastructure with your credentials; your data stays in your systems, and the hosted Conductor sees workflow metadata only. Zero migration.

Why now: the more your team acts on SELECT's Insights, the more often a cheaper model touches a number someone reports. The first win is one domain, read-only, with a check after every cost change that ships. What stays the same: SELECT, your dbt project, your orchestrator and your platform team. The ROI guide shows the math, and the flat-fee explainer covers pricing without a usage meter.

The sentence to repeat upstairs: "SELECT tells us where to save; Data Workers proves the cheaper version is still right, with an approver and a receipt for every change."

Getting started

Start with a pilot. Pick the domain where a wrong number costs the most, such as revenue models on Snowflake, make sure dbt sets query tags, connect Data Workers read-only to Snowflake, the dbt project and your orchestrator, record your key metrics as baselines, and let it check every model your team makes cheaper 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 connect to SELECT? Data Workers connects to SELECT over its API today, and your team's assistant can call SELECT's v2 API side by side with Data Workers' MCP servers. Data Workers reads Snowflake metering and query attribution natively with your own credentials.

Does Data Workers replace SELECT's cost attribution? No. SELECT's views, Usage Groups and budgets stay your view of the bill. Data Workers decodes dbt query tags to trace a model's credits around a fix, so the saving and the correctness sit side by side.

Does Data Workers resize warehouses or change Automated Savings? No. Automated Savings stays with SELECT and your platform team. When a fix needs a warehouse setting, Data Workers drafts it for the platform owner to apply.

What does Data Workers check after a cost change? On Snowflake it checks nulls, uniqueness on key columns and row counts with run_quality_check, compares the metrics your team baselines with monitor_metrics, and reads the dbt manifest to see what changed. Your own dbt tests keep running as before.

What about BigQuery and Databricks? SELECT covers Databricks and has BigQuery in Early Access. Data Workers sums recent BigQuery job bytes into an account-level total and runs its quality checks on BigQuery with service-account credentials. Its per-model cost attribution is built on Snowflake query tags.

Does any billing data go to Data Workers? Data Workers reads Snowflake's account usage views with your credentials, inside your infrastructure. Your data stays in your systems; the hosted Conductor sees workflow metadata only.

Sources

• •SELECT home page (features, platforms, Databricks availability), https://select.dev/ (checked Oct 3, 2026)
• •SELECT, Automated Savings, https://select.dev/features/automated-savings (checked Oct 3, 2026)
• •SELECT for BigQuery (Early Access), https://select.dev/bigquery (checked Oct 3, 2026)
• •SELECT for Databricks, https://select.dev/databricks (checked Oct 3, 2026)
• •SELECT AI policy (last updated Jan 18, 2026), https://select.dev/ai (checked Oct 3, 2026)
• •SELECT changelog, Insight management (Apr 7, 2026), https://select.dev/changelog/2026-04-07-insight-management (checked Oct 3, 2026)
• •SELECT changelog, Increasing the SELECT APIs coverage (Sep 11, 2026; MCP server listed under "Coming soon"), https://select.dev/changelog/select-is-going-headless (checked Oct 3, 2026)
• •SELECT changelog, Query your cost data from the SELECT API (Sep 30, 2026), https://select.dev/changelog/query-your-cost-data-from-the-api (checked Oct 3, 2026)
• •SELECT changelog (Data Transfer attribution Sep 8, 2026; dashboards Oct 1, 2026), https://select.dev/changelog (checked Oct 3, 2026)
• •dbt-snowflake-monitoring (SELECT), query comment and query tag macros, https://github.com/get-select/dbt-snowflake-monitoring (checked Oct 3, 2026)
• •dbt documentation, incremental models and strategies, https://docs.getdbt.com/docs/build/incremental-strategy (checked Oct 3, 2026)
• •Data Workers agent swarm repository: Snowflake metering and query-tag attribution, quality checks, lineage, approvals (checked Oct 3, 2026)
• •Data Workers client setup docs, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)