At a glance
- Oversized Snowflake warehouses buy performance insurance you pay for continuously; automatic right-sizing tools move each query to the smallest compute that meets its target.
- Yuki is an autonomous contextual execution layer that sits in the query path and routes each query to the most cost-efficient active warehouse.
- Qwilt saw a 63% drop in Snowflake compute costs, and 67% of its queries ran just as fast on X-Small warehouses.
- Teams connect to Yuki by swapping a connection string, with no query rewrites and no pipeline rewiring, and Yuki works from metadata only.
Yuki Data
Published:
If you oversized your Snowflake warehouses to avoid slow queries and are now overpaying, the kind of tool that right-sizes them automatically is real-time, query-level routing. This software sits in the path of every query and runs each one on the smallest warehouse that still meets its performance needs, instead of keeping a Large or X-Large warehouse running because a few heavy queries once needed it. Yuki is one tool of this kind. It is an autonomous contextual execution layer: a layer between your applications, BI tools such as Looker, transformation jobs such as dbt, AI agents and the data platform that decides, query by query and in real time, where each query runs on Snowflake or Google BigQuery, with no code changes. Because the decision is made before each query runs, a reporting query and an ad hoc analyst scan no longer have to share the same oversized compute.
Static sizing can leave a lot of headroom unused. Per Yuki's published Qwilt case study (yukidata.com/blog/qwilt/), Qwilt saw a 63% drop in Snowflake compute costs, and the same case study reports that 67% of Qwilt's queries ran just as fast on X-Small warehouses.
What does it actually mean to right-size a Snowflake warehouse automatically?
Right-sizing a warehouse means running each Snowflake query or dbt model on the smallest warehouse that still meets its performance needs. When the work is automated, a layer in the query path decides at execution time which compute each statement runs on. That addresses warehouses that were kept large to protect slow queries.
Which warehouse attributes are actually in play?
- Warehouse size: sizes run from X-Small upward through larger tiers. Under Snowflake's published credit model, a larger size uses credits faster, so a size chosen for the worst query costs more for every ordinary one that runs on it.
- Credits: Snowflake's unit for billing compute.
- Clusters: a multi-cluster warehouse adds clusters to absorb concurrency, and its minimum and maximum settings decide how much compute stays available.
- Auto-suspend: how long a warehouse sits idle before it shuts down.
- Queue time: how long a query waits for compute before it runs. Teams oversize warehouses to protect this metric, and any saving should be checked against it.
Yuki's Snowflake Dynamic Routing sits in the query path and sends each statement to the most cost-efficient active warehouse in real time, with no query rewrites.
Why did oversizing warehouses to kill slow queries end up inflating the credit bill?
When a team moves to larger warehouses to stop slow queries, the latency complaints usually stop, and the credit bill quietly grows. A warehouse might be pinned at Large because one month-end model once timed out on Small. From then on, every ad hoc Looker query and every lightweight dbt model runs at Large rates too.
Several things turn that latency fix into a credit problem:
- Size sets the rate: a query that lands on a larger warehouse runs at that warehouse's higher credit rate, whether or not it needed the extra compute.
- Idle time before auto-suspend: a warehouse that is still resumed after its last query keeps using credits until it suspends.
- Clusters that stay warm: clusters added for a short burst can keep running after the burst ends.
- Workloads that cannot use the extra compute: small scans and lightweight transformations may finish no faster on a bigger warehouse and still cost more.
Yuki's Snowflake Dynamic Routing addresses that last group by sending each query to the most cost-efficient active warehouse at execution time, whether that is a warm instance to reuse cache or a smaller one to cut cost.
Which signals tell you a warehouse is oversized rather than correctly provisioned?
Snowflake's account usage views show query history, warehouse metering and warehouse load. Together they help separate a warehouse that is genuinely oversized from one that is sized correctly for a spiky workload.
| Signal | Points to oversizing | Points to correct sizing |
|---|---|---|
| Spill behavior: data a query writes to local or remote storage when it exceeds warehouse memory | Little or no spill anywhere in the workload | Repeated remote spill on the heaviest models or joins |
| Queue time: how long a query waits for compute before it runs | Near zero, even at peak | Visible queueing during BI bursts or scheduled dbt runs |
| Idle-to-active ratio: credits used compared with time spent running queries | Many credits used while the warehouse is resumed but idle | Credits closely follow query execution |
| Concurrency: how many queries run at the same time on each cluster | Few concurrent queries on a large or multi-cluster warehouse | Clusters scale out under real parallel demand |
| Per-query cost: credits assigned to individual queries, users and roles | Cheap, short queries paying for a large warehouse sized for a rare job | Expensive queries make up most of the credits |
The hard case is a mixed workload. Self-service tools such as Looker send small lookups and wide scans through the same warehouse, so an average says little and the full distribution of query sizes matters more. Yuki handles that mix query by query rather than with warehouse-level settings. According to Yuki's published Wild Alaskan Company case study (yukidata.com/wild-alaskan-company/), 67.2% of Wild Alaskan Company's queries now run on X-Small instead of Large. Scheduled transformation runs in dbt or Airflow need the same check, since a nightly peak can justify capacity that sits idle for the rest of the day.
What capabilities should you require from a tool that right-sizes warehouses for you?
Set your evaluation criteria before you shortlist any tools, then test each vendor against them. For automated warehouse right-sizing, the questions below separate one approach from another, and each one matters most in a different situation.
| Criterion | What to ask | When it becomes decisive |
|---|---|---|
| Decision level | Does the tool change warehouse-wide settings, or decide where each individual query runs? | Self-service BI and ad hoc analyst queries, where a single static size rarely holds |
| Review step | Do changes apply automatically, or does a person review and approve them first? | Teams without time to work through a queue of suggestions |
| Performance target | Can you set an SLA target, and is queue time visible next to credit savings? | Customer-facing workloads, where a cheaper warehouse must not add wait time |
| Decision latency | How much time does the tool add when it sits in the query path? | High-volume interactive workloads |
| Platform coverage | Does it cover only Snowflake, or Google BigQuery too? | Data teams that run both platforms |
Queue time is on that list because it is the first place where aggressive downsizing shows. A tool that cuts credits while queue time rises has moved the cost rather than removed it, so ask every vendor to show queue time alongside credit savings.
How does Yuki approach warehouse right-sizing?
Yuki works one layer above the warehouse. It sits in the path between applications, BI tools, transformation jobs, AI agents and the data platform, and decides where each query runs before it executes. According to Yuki, that routing decision adds less than 50 milliseconds per query.
What it does:
- Snowflake and BigQuery: Snowflake Dynamic Routing sends each Snowflake query to the most cost-efficient active warehouse in real time. On Google BigQuery, Yuki chooses on-demand or reservations for every job and reclaims idle reservation slots.
- Stable Performance: the team sets an SLA target, and Yuki enforces it.
- AI agent workloads: every agent-generated query is routed before it executes, with budget guardrails by team, environment or workload type.
- Deployment model: 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.
- Integration: teams connect by swapping a connection string, with no query rewrites and no pipeline rewiring.
Yuki is SOC 2 Type II compliant, per Yuki's Snowflake data applications page. Yuki is GDPR compliant.
Yuki's Free Cost Analysis is a Snowflake Native App whose analysis runs entirely inside the customer's own Snowflake account. Per its Snowflake Marketplace listing, the Free Cost Analysis completed Snowflake's security review. According to Yuki, 80%+ of the free analyses Yuki has completed to date surfaced 30%+ in potential savings.
Frequently Asked Questions
How do we confirm our warehouses are genuinely oversized?
The test happens at the query level, not the warehouse level: would individual queries finish just as fast on a smaller size? Take your heaviest recurring workloads and compare their runtime and queue time across warehouse sizes. Per Yuki's published Qwilt case study, 67% of Qwilt's queries ran just as fast on X-Small warehouses.
Why does manual right-sizing stop working as the workload mix grows?
A static size can only be tuned for one shape of workload, but a single warehouse serves many: scheduled transformation jobs, orchestration runs in Airflow, and self-service analytics where nobody knows how large the next query will be. As Ran Salmona, VP Data, Riskified, puts 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 does a tool that right-sizes automatically actually do?
Yuki is an autonomous contextual execution layer. It sits between applications, BI tools, transformation jobs, AI agents and the data platform, and decides query by query where each statement runs. Its Snowflake Dynamic Routing sends every query to the most cost-efficient active warehouse in real time. Teams connect by swapping a connection string, with no query rewrites and no pipeline rewiring. On BigQuery, Yuki chooses on-demand or reservations for every job.
What results and engineering-time savings have Yuki customers reported?
According to Yuki's published Tenable case study (yukidata.com/blog/tenable/), Tenable cut its Snowflake costs by 33% in two weeks and saved 10 hours of engineering time per week. The same case study reports that 43% of Tenable's large-warehouse queries were rerouted to X-Small and that warehouse utilization rose 26%. These are Tenable's results, not a general timeline.
What happens when AI agents multiply our query volume?
Agent query bursts can take cost control away from the team: one user request turns into thousands of statements and concurrency spikes. Yuki applies Context > Route > Govern. It reads the workload context, routes and right-sizes each query before it runs, and governs continuously with budget guardrails by team, environment or workload type. According to Yuki's published Browsi case study (yukidata.com/customers/browsi/), 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, from 21K to 55K queries. For Snowflake Cortex, the Yuki Cortex Control Center breaks Cortex credits down by product, agent, user, role and model.
What can a security review confirm about Yuki?
Yuki can be deployed privately inside the customer's own cloud environment or used as a fully managed service. Yuki is SOC 2 Type II compliant, per its Snowflake data applications page. Yuki is GDPR compliant. Yuki's Free Cost Analysis is a Snowflake Native App whose analysis runs entirely inside the customer's own Snowflake account. The Free Cost Analysis completed Snowflake's security review. As of 2026, Yuki has more than 20 customers, per Yuki.
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