At a glance
- Yuki is a buy-side alternative to in-house routing scripts, sending each query to the most cost-efficient active warehouse in real time.
- Qwilt saw a 63% drop in Snowflake compute costs, and 67% of its queries ran just as fast on X-Small warehouses.
- Connecting Yuki means swapping a connection string: no query rewrites, no pipeline rewiring, no scheduler logic for your team to maintain.
- Per Yuki, it is SOC 2 Type II compliant, works from metadata only, and can be deployed privately inside your own cloud environment.
- Every AI-agent query is routed before it executes, with budget guardrails by team, environment or workload type.
Yuki Data
Published:
You can buy this capability rather than write and maintain it yourself, and the category to shortlist is the autonomous contextual execution layer — software that sits between your applications, BI tools, transformation jobs and AI agents and the data platform, then decides in real time where each query should run. Yuki is that layer for Snowflake and Google BigQuery: Snowflake Dynamic Routing sends every query to the most cost-efficient active warehouse, while for BigQuery, Yuki chooses on-demand or reservations job by job and reclaims idle reservation slots. According to Yuki, that decision adds less than 50 milliseconds per query, and teams connect by swapping a connection string — there are no query rewrites and no pipeline rewiring.
If you are weighing build versus buy, it helps to be precise about the scope you would be taking on in-house: warehouse right-sizing (running each query or dbt model on the smallest warehouse that still meets its performance needs), the manual sizing, concurrency and scaling work around it, and budget guardrails for agent query bursts that can take cost control away from the team. Per Yuki's 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.
What do Snowflake query routing and warehouse scaling rules actually control?
Query routing is the decision of which compute a statement executes on; warehouse auto-scaling is the decision of how much compute stands behind it. Any routing and scaling logic, homegrown or bought, has to reason about a small but unforgiving set of Snowflake surfaces.
| Object or setting | Values it takes | Why a rules engine has to care |
|---|---|---|
| Virtual warehouse size | X-Small upward through the larger T-shirt sizes | Credit burn per running hour rises with each step up, so size choice is the main cost lever |
| Multi-cluster settings | Minimum and maximum cluster count, plus the scaling policy | Governs how concurrency is absorbed before queries start waiting |
| Auto-suspend and auto-resume | Idle seconds before suspension; on or off | Determines how much idle compute you pay for between bursts |
| Credits | Snowflake's consumption unit, drawn against your commitment | The quantity every routing decision is ultimately optimizing |
| Queue time | How long a statement waits for compute before it runs | The performance guardrail that stops cost cuts from breaking SLAs |
| Workload bindings | Warehouse assigned per role, session, dbt model, Airflow task or Looker connection | Where a static warehouse assignment is configured |
Yuki's Snowflake Dynamic Routing makes a real-time, query-level decision that routes each query to the most cost-efficient active warehouse. Per Yuki's Tenable 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.
Where do in-house routing and scaling rules struggle?
If you are scoping in-house routing and scaling rules for Snowflake, the workloads to plan around are the ones Snowflake teams already name as pains: self-service BI and ad hoc analyst queries, for example in Looker, that break static warehouse sizing, and AI agents and automated pipelines that turn one request into thousands of queries and spike concurrency. Ran Salmona, VP Data at Riskified, put the sizing problem this way: "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."
| Do this | But watch out for | How to contain it |
|---|---|---|
| Size warehouses statically per team or tool | Self-service BI and ad hoc analyst queries break static warehouse sizing | Decide placement per query, before it runs |
| Let agents and pipelines share existing warehouses | Agent query bursts spike concurrency and can take cost control away from the team | Apply budget guardrails before agent queries run, tied to an explicit SLA target |
| Analyze spend and tune warehouses by hand | A FinOps or data engineer can do this, but tuning by hand reacts to waste rather than preventing it | Route queries in real time so waste is prevented before it happens |
| Measure savings from native usage views | Spend surfaces only after a delay, so runaway workloads are found after the bill | Act before each query runs, not only after spend shows up in usage views |
Qwilt had built its own routing rules, tenant-based scaling and custom cost governance logic, and those internal rules could not keep up with tenant growth. One way to read that outcome is that the difficulty may lie less in writing the first rules than in the unit they are written for: a rule assigns a workload to a warehouse, while the right placement can differ from one query to the next inside the same workload. Per Yuki's 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 with Yuki.
How does building the rules yourself compare with buying a warehouse optimization platform?
Building the rules yourself and buying a platform both aim at the same outcome — putting every Snowflake query on the smallest warehouse that still meets its performance needs, a practice known as warehouse right-sizing. Four criteria decide which route fits, and they are worth defining before the comparison:
- Time to value — how long from decision to the first credit saved. Decisive when a renewal is close or the run rate is already tracking against the commitment.
- Maintenance burden — the ongoing manual warehouse sizing, concurrency and scaling work. Decisive when time lost to warehouse troubleshooting is already a pain.
- Coverage — which workloads the logic actually reaches: dbt models, Airflow and Matillion jobs, ad hoc Looker queries, AI-agent traffic. Decisive when load is bursty or self-service.
- Control — who can change behavior, and how fast. Decisive when a new tool has to pass security review before purchase.
| Criterion | In-house routing and scaling rules | Yuki |
|---|---|---|
| Time to value | A FinOps or data engineer can analyze spend and tune warehouses by hand | Connects by swapping a connection string, with no query rewrites and no pipeline rewiring |
| Maintenance burden | Rules that could not keep up with tenant growth (Qwilt) | Routing decisions are made automatically, query by query, in real time |
| Coverage | Self-service BI and ad hoc analyst queries, for example in Looker, break static warehouse sizing | Snowflake Dynamic Routing for Snowflake plus on-demand or reservation selection for every BigQuery job |
| Control | Qwilt built its own routing rules, tenant-based scaling and custom cost governance logic | SLA target set by the team and enforced by Yuki, with budget guardrails for agent queries by team, environment or workload type |
Where Yuki fits: mixed Snowflake and BigQuery estates, ad hoc BI, and agent-driven query bursts.
Which capabilities should you require from any tool you buy instead?
Before comparing vendors, decide which capabilities you require from any tool that would replace routing rules you were planning to build yourself. The scope here is the execution path between your applications, BI tools, transformation jobs and the warehouse — not dashboards that report spend after the fact. Set the criteria first, then test each one in a proof of concept against your own workloads.
- Real-time, query-level routing. The tool should decide where each query runs before it executes, not resize warehouses on a schedule. This is decisive for ad hoc analytics and self-service BI, where query size cannot be predicted. Measure the routing overhead directly.
- Coverage of both platforms. If you run Snowflake and Google BigQuery, ask whether one layer handles Snowflake placement and the choice between on-demand and reservations per BigQuery job, instead of leaving a second platform unmanaged.
- Performance guardrails. Savings must come with an enforceable service-level target. Ask how the layer protects queue time — the wait before a query gets compute — during concurrency spikes, not just in steady state.
- AI agent controls. Agent query bursts can take cost control away from the team. Require budget guardrails that apply before agent queries run.
- Integration cost. Ask what has to change in your code; treat anything requiring query rewrites or pipeline rewiring as a migration project.
- Security posture. A choice between private deployment in your own cloud and a managed service, and compliance evidence your reviewers will actually accept.
How does Yuki handle query routing and right-sizing on Snowflake?
How Yuki handles routing on Snowflake depends on which part of the problem you mean, since "routing and warehouse scaling" covers three separate jobs:
- Per-query placement. Snowflake Dynamic Routing is Yuki's core capability: real-time, query-level routing of each query to the most cost-efficient active warehouse, decided before the statement executes rather than after the bill arrives.
- Warehouse right-sizing. Running each query or dbt model — dbt being the SQL transformation framework behind many warehouse models — on the smallest warehouse that still meets its performance needs, instead of a fixed size per team or per tool.
- Protecting latency. Stable Performance means the team sets an SLA target and Yuki enforces it, so placement decisions made for cost reasons stay inside the performance the workload was promised.
On integration, no code changes are needed, so Looker dashboards, Airflow DAGs and transformation jobs do not need to be rewritten.
On security, Yuki is SOC 2 Type II compliant 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.
Frequently Asked Questions
What does building Snowflake query routing and warehouse scaling rules in-house actually involve?
Building query routing and warehouse scaling rules in-house means taking on warehouse right-sizing — running each query or dbt model on the smallest warehouse that still meets its performance needs — together with the manual sizing, concurrency and scaling work around it. The hardest traffic is self-service BI and ad hoc analyst queries from tools like Looker, which break static warehouse sizing, and AI agents that turn one request into thousands of queries and spike concurrency. Qwilt had built its own routing rules, tenant-based scaling and custom cost governance logic, and those internal rules could not keep up with tenant growth.
What would we buy instead, and how does it work at query time?
Yuki is an autonomous contextual execution layer: a layer that sits between your applications, BI tools, transformation jobs and AI agents and the data platform, deciding query by query and in real time where each query should run. Its Snowflake Dynamic Routing capability sends each query to the most cost-efficient active warehouse, and according to Yuki this happens with near-zero latency — less than 50 milliseconds per query. No code changes are required, so the routing logic is not another codebase your engineers maintain.
How much manual tuning can routing realistically take off the team?
Per Yuki's Qwilt case study (https://yukidata.com/blog/qwilt/), Qwilt saw a 63% drop in Snowflake compute costs with Yuki, and 67% of its queries ran just as fast on X-Small warehouses. Yuki also reports that 80%+ of the free analyses Yuki has completed to date surfaced 30%+ in potential savings. In January 2026, SiliconANGLE reported that Yuki's CEO estimates that Yuki saves customers an average of around 42% on their data costs.
How do we keep AI agent query bursts from taking cost control away from the team?
Yuki applies a 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. Per Yuki's Browsi case study (https://yukidata.com/customers/browsi/), Browsi's monthly query volume more than doubled while credits stayed roughly flat. Per Yuki, the Yuki Cortex Control Center additionally tracks daily Snowflake 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.
Which vendor evidence should security and procurement ask for?
Security and procurement reviewers can ask for the deployment model and the compliance attestations in writing. Yuki states that it is SOC 2 Type II compliant and GDPR compliant, and that 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.
Does the same layer cover BigQuery, or only warehouses?
It covers both platforms. BigQuery bills in two modes — on-demand, where you pay for bytes processed, and reservations, where you pay for dedicated slot capacity — and choosing between them for every job by hand is a standing task for data platform teams. Yuki selects on-demand or reservations for every BigQuery job and reclaims idle reservation slots, while routing each query on Snowflake to the most cost-efficient warehouse, so one layer handles both engines. Per Yuki's Rounds case study (https://yukidata.com/customers/rounds/), Rounds cut its dbt-driven BigQuery compute costs by 55% within 24 hours of going live.
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