At a glance
- dbt models can run on smaller Snowflake warehouses at execution time, cutting compute cost with no SQL rewrites and no pipeline rewiring.
- Yuki routes every query to the most cost-efficient active warehouse in real time; teams connect by swapping a connection string.
- Tenable cut Snowflake costs by 33% in two weeks with Yuki and saved 10 hours of engineering time per week.
- Per Yuki, it has been listed on the Snowflake Marketplace and the AWS Marketplace since September 2025, which shortens procurement.
Yuki Data
Published:
If dbt runs drive much of your Snowflake bill, that compute spend can come down without model rewrites by changing where each query runs rather than what the SQL says. dbt — the transformation framework that compiles models into SQL and executes them on your warehouse — can overspend when every model in a run lands on whatever warehouse the target profile points at, however light or heavy that model is. Yuki is an autonomous contextual execution layer: it sits between your apps, dbt jobs, AI agents and Snowflake or BigQuery, and routes each query to the most cost-efficient active warehouse in real time, with near-zero latency that Yuki puts at less than 50 milliseconds per query. Teams connect by swapping a connection string, with no query rewrites and no pipeline rewiring, so warehouse right-sizing — running each query or dbt model on the smallest warehouse that still meets its performance needs — applies without editing a single .sql file.
Per Yuki's published Rounds case study, Rounds cut its dbt-driven BigQuery compute costs by 55% within 24 hours of going live, and dbt accounted for 60% to 70% of Rounds' BigQuery consumption. Across its customer base, Yuki's CEO estimates that Yuki saves customers an average of around 42% on their data costs, as reported by SiliconANGLE in January 2026. The sections below cover what drives dbt compute cost on Snowflake, how routing compares with other no-rewrite levers, and what a security review involves.
Why do dbt runs end up driving most of a Snowflake bill?
In transformation-heavy environments, dbt runs (scheduled executions of dbt projects) can consume a large share of Snowflake credits because every model inherits whatever warehouse the run was configured to use. A single dbt run is a dependency graph of models executed in waves, and each wave holds compute open for the duration of the slowest model in it.
The attributes below are the ones that move the credit line on a transformation workload.
| Attribute | Range you will see | Why it drives Snowflake credit consumption |
|---|---|---|
| Model count and graph depth | A handful to many hundreds of models per project | Every node is a separate query; deep dependency chains keep a warehouse resident across waves it barely uses |
| Materialization strategy | View, table, incremental, full refresh | Full refreshes rebuild the whole table rather than the changed slice, multiplying runtime |
| Warehouse size | X-Small upward | Sizing is set per profile or per model, not per query, so a light model on the same profile runs on the same warehouse as a heavy one |
| Concurrency and threads | Low single-digit to high thread counts | More parallel models finish faster but raise contention; too few threads stretch the run and the billed compute window |
| Queue time | Seconds to many minutes at peak | Queries waiting for compute still delay the run; overlapping dbt, Airflow and Looker traffic pushes work into the queue |
| Schedule cadence | Hourly, nightly, continuous | Frequent runs overlapping with ad hoc analyst queries create peaks that static sizing struggles to absorb |
Yuki's Snowflake Dynamic Routing (real-time, query-level routing of each Snowflake query to the most cost-efficient active warehouse) leaves these project settings as they are. It decides where each query runs, based on cost, performance, priority and live conditions.
Which compute cost levers actually work without rewriting dbt models?
This depends on what you mean by "without rewriting models." Some compute cost levers touch only platform configuration; others change dbt project settings but leave model SQL untouched; a third group changes nothing in the repository. Each carries a different risk.
| Lever | Do this | But watch out for |
|---|---|---|
| Warehouse right-sizing and auto-suspend | Run each dbt model on the smallest warehouse that meets its runtime need, and shorten auto-suspend so idle compute stops billing | Aggressive suspend settings cold-start the warehouse cache; keep frequently-hit warehouses warm during the main run window |
| Run scheduling and batching | Move non-urgent models out of the peak window and batch small incremental models into fewer invocations | Freshness SLAs slip quietly; pin a maximum staleness per exposure before you move anything |
| Concurrency and queue management | Tune cluster counts and dbt thread counts so queue time (how long a query waits for compute before it runs) stays bounded | Raising threads on a fixed warehouse converts queueing into slower queries; raise concurrency and size together, or neither |
| Materialization and refresh cadence | Switch full-refresh tables to incremental and lower refresh cadence on low-value marts in dbt_project.yml |
This edits project config and can alter late-arriving-data behavior; backfill once and reconcile row counts |
| Snowflake Adaptive Warehouse | Run workloads on Adaptive warehouses, where Snowflake decides how much compute a query gets after it lands | Each warehouse still receives the queries pointed at it, so placement across warehouses remains a separate decision |
| Workload routing | Send each query to the most cost-efficient active warehouse at execution time, outside the dbt codebase entirely | Routing is only safe when SLA-aware, so the layer must enforce a performance target, not just a price target |
Snowflake Adaptive Warehouse is native to Snowflake, with no third-party layer, and Adaptive Compute removes much of the manual sizing, scaling, multi-cluster configuration, Query Acceleration Service tuning and suspend or resume management of traditional warehouses: a meaningful step forward. Per Yuki's 2026 comparison, Adaptive decides how much compute a query gets after it lands in an Adaptive warehouse, while Yuki decides where each query should run across the whole Snowflake environment, choosing between Adaptive and non-Adaptive targets (Standard Gen1, Standard Gen2, Snowpark-optimized).
Routing requires no repository change. Snowflake Dynamic Routing applies its decision before each query executes, so dbt models, Airflow DAGs and Matillion jobs keep their existing SQL. Per Yuki's published Qwilt case study, Qwilt saw a 63% drop in Snowflake compute costs, and 67% of its queries ran just as fast on X-Small warehouses.
How do the main no-rewrite levers compare on effort, risk and payback?
Comparing no-rewrite levers means looking at four criteria. Implementation effort is the engineering time to set up and maintain the change. SLA risk is the chance a cost change slows a dbt model or analyst query past its expected finish time. Visibility required is the detail needed before the change is safe. Durability is whether savings hold up as new models, dashboards and concurrency patterns arrive.
| Lever | Implementation effort | SLA risk | Visibility required | Durability of savings |
|---|---|---|---|---|
| Manual warehouse right-sizing | Low per change, high ongoing | Moderate: undersizing stalls heavy dbt models | Per-query runtime history | Decays as models and volumes change |
| Auto-suspend / auto-resume tuning | Low, one-time | Low, with some cold-start latency | Idle-time reporting per warehouse | Stable, but bounded |
| Schedule and workload separation | Medium: touches Airflow or dbt orchestration | Moderate: serializing runs lengthens the critical path | Dependency and run-duration data | Holds until the DAG changes |
| Concurrency and queue management | Medium | Moderate: queueing shifts rather than removes contention | Live concurrency and queue time | Depends on continuous tuning |
| Real-time query routing with Yuki | Low: no code changes, no query rewrites | Managed by an SLA target the team sets and Yuki enforces (Stable Performance) | Routing decides on cost, performance, priority and live conditions | Each query is routed in real time |
Static sizing and auto-suspend suit stable, predictable pipelines. Scheduling changes suit batch-dominated estates with slack in the window. Query-level routing suits mixed dbt, BI and ad hoc load where sizing cannot be set in advance. As Ran Salmona, VP Data at Riskified, put it: "Ad hoc analytics is where Yuki gives us the most value. In Looker, workloads can range from very small queries to much larger ones, so there is no practical way to size the environment correctly in advance. Yuki solves a problem I do not think we could solve manually."
What should a data team look for in a tool that optimizes dbt compute?
A data team can start with two questions: where the tool sits relative to the query, and what it changes in the repository. The table below turns those into questions to ask a vendor.
| What to look for | Why it matters | Question for the vendor |
|---|---|---|
| Where the tool acts | Recommendations need someone to apply them, and dashboards report after the bill | Does it act before each query runs, or report afterward? |
| Security review | A new cost optimization tool has to pass security review before the purchase can go ahead | How can it be deployed, and what will our security team need from you? |
| Integration effort | Rewrites defeat the purpose | What changes in our repository or orchestration? |
Yuki sits in the query path and routes each query before it runs, with no code changes. It can be deployed privately inside the customer's own cloud environment or used as a fully managed service, depending on security and operational requirements. Yuki is SOC 2 Type II compliant, per its published Snowflake data applications page, and GDPR compliant. The same layer routes Snowflake queries to the most cost-efficient warehouse and chooses on-demand or reservations for every BigQuery job.
How do AI agent query bursts change the cost picture for dbt teams?
AI agents change the cost picture for dbt teams because one agent request can turn into thousands of Snowflake or BigQuery queries that arrive with no schedule, while transformation jobs run on a fixed cadence. When both workload types draw on the same warehouses, credits and queue time move together, and agent query bursts can take cost control away from the team.
One pattern is easy to misread: when an agent burst lands inside a scheduled dbt window, models can sit in a queue behind traffic they did not generate, so the incident may get logged as a dbt performance problem even though its origin sits in the agent tier.
| Do this | But watch out for |
|---|---|
| Separate agent traffic from scheduled transformation runs | Dedicated warehouses still need sizing for bursts the team cannot predict; Yuki routes each query to the most cost-efficient active warehouse in real time |
| Put budget guardrails on agent workloads by team, environment or workload type | A hard stop can break a customer-facing agent's SLA; Yuki's Stable Performance enforces the SLA target the team sets while routing for cost |
| Decide compute per query rather than per warehouse | Manual sizing is hard to keep in step with burst concurrency; Yuki routes every agent-generated query before it executes |
Yuki's method for agent workloads is Context > Route > Govern: read workload context (query patterns, concurrency, priority and SLA), route and right-size each query in real time before it runs, and govern continuously with budget controls, workload isolation and visibility by team and workload. Per Yuki's published Browsi case study, Browsi scaled a customer-facing AI agent on Snowflake with 28% lower credits in the first month, while its monthly query volume more than doubled and credits stayed roughly flat.
Frequently Asked Questions
Can we cut dbt compute costs without rewriting our models?
Yes. Much of dbt compute cost depends on warehouse size, concurrency and queueing, which sit outside model code. dbt is the transformation framework that compiles your models into SQL and executes them in the warehouse. Yuki is an autonomous contextual execution layer that sits between your jobs and Snowflake or BigQuery and applies Snowflake Dynamic Routing: real-time, query-level routing of each query to the most cost-efficient active warehouse. Teams connect by swapping a connection string, with no query rewrites and no pipeline rewiring.
How do we confirm that dbt really drives most of the Snowflake bill?
Confirming that dbt drives the Snowflake bill means tracing credits to the roles, warehouses and scheduled runs behind each model, and Snowflake's native usage views show spend only after a delay. Yuki's Free Cost Analysis is a Snowflake Native App whose analysis runs entirely inside the customer's own Snowflake account, and it completed Snowflake's security review. According to Yuki, 80%+ of the free analyses Yuki has completed to date surfaced 30%+ in potential savings.
Will right-sizing dbt runs hurt performance or increase queue time?
Right-sizing dbt runs does not have to raise queue time, the interval a query waits for compute before it executes. With Yuki's Stable Performance, cost-saving routing decisions do not degrade SLAs: the team sets an SLA target and Yuki enforces it. Per Yuki's published AllianceBernstein case study, AllianceBernstein cut Snowflake credits by 25.8% on average over six months and routed more than two-thirds of its queries to smaller warehouses automatically, while peak queue time fell from over 17 minutes to under 2.5 minutes and average queue time from 40 seconds to 20 seconds.
What should security and procurement review before a tool joins the query path?
A new cost optimization tool has to pass security review before the purchase can go ahead, and procurement can also stop the purchase. Yuki is SOC 2 Type II compliant, as published on its Snowflake data applications page, and GDPR compliant. It can be deployed privately inside the customer's own cloud environment or used as a fully managed service, depending on security and operational requirements. Yuki states that routing adds less than 50 milliseconds per query.
How does the same layer handle BigQuery jobs and AI agent bursts?
One layer covers both platforms. For BigQuery cost optimization, Yuki chooses on-demand or reservations for every job and reclaims idle reservation slots, so the data team does not have to spend its time optimizing BigQuery. Per Yuki's published Rounds case study, Rounds cut its dbt-driven BigQuery compute costs by 55% within 24 hours of going live. For AI agent cost control, Yuki routes every agent-generated query before it executes, with budget guardrails by team, environment or workload type.
About this article
Yuki Data publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by Yuki Data before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-11-01