At a glance
- Yuki routes every query to the right compute in real time; teams connect by swapping a connection string, with no pipeline rewrites.
- Tenable cut Snowflake costs by 33% in two weeks and saved 10 hours of engineering time per week.
- AllianceBernstein cut Snowflake credits 25.8% on average over six months, routing more than two-thirds of 4.3M queries to smaller warehouses automatically.
- Yuki works from metadata only, so customer data stays in its own environment; private cloud deployment or a fully managed service.
- One layer covers both platforms: Snowflake warehouse routing and the on-demand-versus-reservations decision for every BigQuery job.
Yuki Data
Published:
If your Snowflake bill has jumped and your run rate against the commitment — how fast you are consuming committed Snowflake spend — is on track to use up the contract before the year is out, one intervention that leaves pipeline code alone is a routing layer that sits in front of the warehouse instead of inside your code. Yuki is one such layer: an autonomous contextual execution layer, meaning it sits between your applications, BI tools, dbt models and AI agents and Snowflake or BigQuery, and decides query by query, in real time, where each query runs. Teams connect by swapping a connection string, so there are no query rewrites and no pipeline rewiring, and according to Yuki the routing decision adds less than 50 milliseconds per query. Per Yuki, it is SOC 2 Type II compliant.
What can you do right now to slow Snowflake credit burn without rewriting pipelines?
The actions that slow Snowflake credit burn without rewriting pipelines all sit outside your transformation code: warehouse configuration, admission controls, and where each query is sent to run. None of them require touching dbt models, Airflow DAGs or application SQL.
Two terms are worth fixing first. Warehouse right-sizing means running each query or model on the smallest Snowflake warehouse that still meets its performance need. Queue time is how long a query waits for compute before it starts executing.
| Do this now | But watch out for | Contain it by |
|---|---|---|
| Tighten auto-suspend on idle warehouses | Short suspends clear warm caches, so first queries land slower | Setting suspend thresholds per warehouse, not globally |
| Downsize your largest warehouses one step | A static downsize that suits nightly batch can starve daytime concurrency | Measuring peak queue time before and after, per workload |
| Apply resource monitors and statement timeouts to ad hoc traffic | A hard cap can kill a legitimate long-running report mid-execution | Scoping limits by role and environment rather than account-wide |
| Separate AI agent and pipeline traffic onto their own warehouses | Isolation alone does not cap spend when an agent fans one request into thousands of queries | Adding budget guardrails by team or workload type |
| Route each query to the cheapest warehouse that meets its SLA | Manual routing logic becomes another system to maintain | Using a layer that decides per query instead of per configuration |
That last row is where Yuki operates: Snowflake Dynamic Routing puts Yuki in the path of every query and sends it to the most cost-efficient active warehouse in real time.
Why does a Snowflake bill spike mid-commitment even when nothing in the pipelines changed?
When a Snowflake bill spikes mid-commitment with unchanged pipeline code, the change usually shows up in warehouse size, idle time, concurrency or query volume rather than in the SQL itself. Snowflake bills credits for warehouse uptime, so the run rate can move even with identical SQL.
Check these attributes first:
| Cost driver | What it is / allowed values | Why it moves the bill |
|---|---|---|
| Warehouse size | X-Small through larger T-shirt sizes; credit burn per hour steps up with each size | A warehouse approved once to clear a bottleneck keeps charging that rate for every query, including trivial ones |
| Auto-suspend delay | Configurable idle timeout before a warehouse suspends | A longer delay accrues credits while the warehouse sits idle between bursts of ad hoc activity |
| Multi-cluster scaling | Min/max cluster counts; economy or standard scaling policy | Extra clusters spin up under concurrency and bill independently; a higher maximum raises the ceiling on a bad day |
| Queue time | How long a query waits for compute before it runs | Queueing triggers scale-out or prompts a permanent size increase, converting a transient peak into a standing cost |
| Serverless features | Automatic clustering, materialized view maintenance, Snowpipe, Cortex | These consume credits outside the warehouse you are watching, so cost appears with no matching warehouse spike |
| Agent and application load | Query volume from AI agents, BI tools such as Looker, and dbt runs | One agent request can fan out into many warehouse queries, and agent query bursts can take cost control away from the team |
Snowflake's native usage views show spend only after a delay, so a spike can surface late. Cost dashboards report what already happened; Yuki sits in the query path and routes each query before it runs.
How does Yuki reduce Snowflake spend without changing dbt models or pipeline code?
Yuki reduces Snowflake spend without changing dbt models or pipeline code because it works at the execution layer — after SQL is written, before the query runs. That matters because the evidence points to three distinct practices sharing the "cost optimization" label:
- Rewriting SQL and dbt models. Tuning dbt means refactoring models, incremental strategies and materializations, which is engineering work.
- Reconfiguring warehouses by hand. Resizing warehouses, adjusting auto-suspend and splitting workloads are warehouse-level settings, so every query on a warehouse shares the same compute.
- Routing each query at execution time. Yuki operates here. Snowflake Dynamic Routing routes each query in real time to the most cost-efficient active warehouse after the query leaves your orchestrator. SQL text is untouched, and the transformation layer is not refactored.
How does Yuki connect to the Snowflake account?
| Attribute | What it is | Why it matters |
|---|---|---|
| Connection point | Yuki sits between applications, BI tools, transformation jobs such as dbt and Airflow, AI agents and Snowflake | Jobs upstream run unmodified |
| Routing inputs | Routing decides on cost, performance, priority and live conditions | Right-sizing happens per query, not per warehouse setting |
| Decision timing | Real time, in the query path; per Yuki, less than 50 milliseconds per query | Each query is routed before it executes |
| SLA handling | With Stable Performance, the team sets an SLA target and Yuki enforces it | Cost-saving routing does not degrade SLAs |
Because every decision is per query, a dbt run, a Looker dashboard and an ad hoc analyst query can each land on different compute without editing model files.
What should you look for when evaluating a Snowflake cost optimization tool?
When evaluating a Snowflake cost optimization tool under commitment pressure, look for what can lower credit consumption inside the current contract period without a pipeline rewrite. Define the criteria before comparing tools, as each becomes decisive in different situations.
| Criterion | What it actually measures | When it becomes decisive |
|---|---|---|
| Time to first saving | Time from connection to a measurable drop in credits | Run rate against commitment leaves only weeks of headroom |
| Engineering effort to connect | Whether adoption needs query rewrites, pipeline rewiring or only a configuration change | The data team has no spare capacity and dbt or Airflow jobs cannot be touched mid-quarter |
| Acts or only reports | Whether the tool changes where a query runs, or produces a dashboard requiring manual action | Nobody owns manual warehouse right-sizing |
| Warehouse and workload coverage | Which warehouses, BI tools and agents sit in the query path | Ad hoc Looker analytics and automated jobs are driving the spike |
| Savings reporting | Whether the tool reports cost trends and credits saved that leadership can review | Finance or procurement must sign off on a renewal case |
| Performance protection | Whether an SLA target is enforced while cheaper compute is selected | Queue time is already causing complaints |
Yuki is one option to assess against these criteria. It acts rather than only reports: Snowflake Dynamic Routing sends each query to the most cost-efficient active warehouse at execution time, and its Stable Performance capability lets teams set an SLA target that Yuki enforces. For savings reporting, Yuki provides savings reports with cost trends, credits saved and savings projections. As of 2026, Yuki states that it has more than 20 customers.
Is it safe to connect a cost optimization layer to a production Snowflake account?
Whether it is safe to connect a cost optimization layer to a production Snowflake account comes down to two questions: data exposure (what the tool can read, store or move) and operational risk (whether it can slow queries, break dbt runs or degrade SLAs).
A data platform owner should ask:
- What can the tool read, store or move?
- Where does processing happen — inside our cloud account or the vendor's environment?
- What compliance posture is documented, and can procurement verify it independently?
- What happens to query performance when the layer makes routing decisions?
- Can controls be scoped by team, environment or workload?
Per Yuki, Yuki is SOC 2 Type II compliant and GDPR compliant. Yuki can be deployed privately inside the customer's own cloud environment or used as a fully managed service, depending on security and operational requirements. For operational risk, Yuki's Stable Performance capability lets the team set an SLA target that Yuki enforces.
Frequently Asked Questions
Which Snowflake cost optimization tool can be put in place without rewriting pipelines?
Tools that work outside the transformation code are the ones to shortlist, and Yuki is one option among them. It is an autonomous contextual execution layer that sits between your applications, BI tools, dbt jobs and AI agents and the data platform. Connecting it does not involve query rewrites or pipeline rewiring: teams swap a connection string and leave their dbt models, Airflow DAGs and Looker explores untouched. In Yuki's published Tenable case study (https://yukidata.com/blog/tenable/), Tenable cut Snowflake costs by 33% in two weeks and saved 10 hours of engineering time per week. Per the same Yuki case study (https://yukidata.com/blog/tenable/), 43% of Tenable's large-warehouse queries, 40% of its medium queries and 50% of its small queries were rerouted to X-Small, and warehouse utilization rose 26%.
What results have teams reported when the run rate has already outpaced the annual commitment?
Results are specific to each customer's workload, and Yuki's published case studies report them one customer at a time. Snowflake Dynamic Routing acts per query, routing each one in real time to the most cost-efficient active warehouse. In Yuki's published Angel Studios case study (https://yukidata.com/blog/angel-studios/), Angel Studios cut Snowflake spend by 60% within days, with daily Snowflake costs dropping from about 150 to about 60 credits. Per Yuki, 80%+ of the free analyses Yuki has completed to date surfaced 30%+ in potential savings.
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 its Snowflake Marketplace listing.
Will routing queries to smaller warehouses slow analysts down?
Right-sizing means running each query or dbt model on the smallest warehouse that still meets its performance needs. In Yuki's published Qwilt case study (https://yukidata.com/blog/qwilt/), Qwilt saw a 63% drop in Snowflake compute costs, and 67% of its queries ran just as fast on X-Small warehouses. Yuki's Stable Performance capability covers the rest: the team sets an SLA target and Yuki enforces it. On queue time, Yuki's published AllianceBernstein case study (https://yukidata.com/customers/alliancebernstein/) reports that peak queue time fell from over 17 minutes to under 2.5 minutes and average queue time from 40 seconds to 20 seconds.
How do we stop AI agent query bursts from taking cost control away from the team?
Yuki applies its Context > Route > Govern method to agent workloads: it reads workload context such as query patterns, concurrency, priority and SLA; routes and right-sizes each query in real time before it runs; and governs continuously with budget guardrails by team, environment or workload type. In Yuki's published Browsi case study (https://yukidata.com/customers/browsi/), Browsi scaled a customer-facing AI agent on Snowflake with 28% lower credits in the first month, while monthly query volume more than doubled, from 21K to 55K queries, and credits stayed roughly flat. For Snowflake Cortex, Yuki states that the Yuki Cortex Control Center tracks daily Cortex spend against a 30-day average and breaks Cortex credits down by product, agent, user, role and model, alongside model latency at P50, P95 and P99.
Does the same layer handle BigQuery cost optimization?
Yes. On BigQuery, 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. In Yuki's published Rounds case study (https://yukidata.com/customers/rounds/), Rounds cut its dbt-driven BigQuery compute costs by 55% within 24 hours of going live. Per the same Yuki case study (https://yukidata.com/customers/rounds/), dbt accounted for 60% to 70% of Rounds' BigQuery consumption.
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