BigQuery spend has a habit of creeping back up, especially when your data footprint and analytics usage are growing at the same time. Even if your team is doing the right things, the bill can still keep climbing.
Rounds hit that wall. Then they found a lever that actually moved the needle, fast.
In under 24 hours, they cut dbt-driven BigQuery compute costs by 55%, without re-architecting their platform, rewriting dbt models, or turning their data team into full-time “cost police.”
This is how they did it, and what it unlocked.
About Rounds
Rounds turns mobile assets into businesses. Their “Machine” is an autonomous, data-powered AI platform that streamlines the mobile asset lifecycle, from sourcing and evaluation to continuous optimization.
Their stack runs primarily on GCP, with BigQuery at the core of analytics, dbt for transformations, and Looker Studio for reporting.
As their workloads scaled over the last 18 months, more sources came online, usage expanded across the business, and compute costs rose right alongside it.
Data Stack
- BigQuery
- dbt
- Looker Studio
The Challenge: Compute Costs Kept Growing, Even After “Doing the Right Things”
Rounds didn’t ignore optimization. They were already more disciplined than most teams.
Before Yuki, they invested in cost visibility and controls:
- They analyzed BigQuery query metadata.
- They broke costs down by user and domain.
- They built dashboards to understand where spend was coming from.
Then they went after the actual waste.
They tackled high-cost query patterns, including repeated scans caused by iterative workflows, especially “looping” development-driven processes.
They created purpose-built materialized views and reduced per-query scan volume dramatically, cutting waste without changing business outputs.
So why didn’t this solve it?
Because BigQuery cost optimization has a brutal truth baked in:
Visibility is not the same thing as execution.
You can see exactly what’s expensive and still not have time to fix it.
Rounds was scaling fast. The data team’s job was to deliver platform outcomes for the business, not run an ongoing optimization program. Action items didn’t always get executed because priorities shifted to product work and business enablement.
Meanwhile, costs kept rising with scale.
As Hannan (Rounds’ Head of Data Engineering and Science) put it, BigQuery billing behaves differently than Snowflake. With BigQuery on-demand, spend grows with the size of data scanned, and as volumes grow, costs can inflate quickly.
When your data grows 2x, your cost problem often grows more than 2x, because you’re not just storing more data, you are scanning more data, more often, across more use cases.
Why reservations weren’t a clean answer
Rounds also looked at BigQuery reservations.
But reservations can feel like trading one set of problems for another:
- You commit to capacity upfront.
- Workloads are mixed, spiky, and hard to predict.
- A one-size-fits-all reservation model can force you into bigger architectural changes just to make billing behave.
Rounds wanted flexibility and cost control, without committing to a model that could become its own constraint.
They needed a solution that worked with reality:
- mixed workloads
- a busy team
- growing usage
- no appetite for a big re-architecture project just to “fix the bill”
The Shift: Stop Treating Cost Optimization Like a Project
Most teams treat BigQuery optimization as a series of projects:
- a query rewrite initiative
- a partitioning sprint
- a materialization effort
- a “cost cleanup week”
That helps, but it rarely sticks, because the underlying system keeps changing:
- new sources
- new dashboards
- new developers
- new models
- new users
- new scanning patterns
Rounds already proved they could optimize. What they needed was a way to keep optimizing, without adding more work.
They needed a lever that:
- produced immediate savings
- didn’t require changing dbt
- didn’t fight the roadmap
- didn’t create performance risk
The Solution: Per-Query Routing for dbt, Without Changing dbt
Rounds deployed Yuki specifically on their dbt workload, which represented roughly 60% to 70% of their BigQuery consumption.
That choice matters.
When you want fast savings, you don’t start with “everything.” You start where the spend is concentrated and repeatable.
dbt is exactly that: lots of scheduled transformations, lots of consistent query patterns, lots of predictable leverage.
Where Yuki fits
Yuki sits between dbt and BigQuery.
For each dbt query, Yuki evaluates execution characteristics and routes it to the most cost-efficient billing path in real time, without requiring changes to dbt models or workflows.
What Yuki delivered for Rounds
Immediate cost reduction without infrastructure changes
Rounds could capture meaningful savings before deeper refactoring initiatives, without making platform changes the team didn’t have time to do.
A practical “first reduction” lever that doesn’t compete with the roadmap
Instead of burning cycles on another optimization program, they got a lever that runs in parallel with business priorities.
No impact on performance
Their daily dbt pipelines continued running as usual while costs dropped.
This is the key difference between “optimization work” and “optimization automation.”
One steals roadmap time. The other gives it back.
The Results: 55% Savings on BigQuery dbt Compute
Within 24 hours of going live, Rounds measured consistent savings:
- 55% average reduction in dbt BigQuery compute costs (confirmed via weekly and monthly checks)
- Savings significant enough to materially change prioritization and planning across the data team
Hannan described the impact clearly: cost was the critical constraint, and reducing it removed friction across the team.
“Yuki removed a huge amount of friction. The 55% savings were immediate, but the bigger win was predictability. We can forecast BigQuery spend with confidence now, and reinvest that headroom into AI initiatives instead of constantly policing costs.”
Hannan Kravitz, Head of Data Engineering and Science at Rounds
That quote is the real story.
55% is the headline.
Predictability is the compounding advantage.
What This Unlocked for Rounds
Most cost stories stop at “we saved money.”
This one is more interesting, because the savings changed what the team could say yes to.
Rounds didn’t just get budget relief. They got optionality:
- More confidence to invest in new initiatives, including AI-related tooling, without fear of runaway analytics costs.
- Less time and energy spent acting as “cost police,” more time spent building and improving the platform.
That’s what happens when you remove cost as a constant constraint.
You stop negotiating every new use case.
You stop delaying projects because “we can’t afford the compute.”
You stop burning engineering cycles on incremental tuning that never ends.
As our CEO put it:
“Cost savings aren’t the goal. Optionality is. Rounds cut BigQuery spend with zero disruption, and that gave the team room to say yes to AI initiatives, new data use cases, and faster iteration, without worrying about the next bill.”
Ido Arieli Noga, CEO and Co-Founder at Yuki
Takeaways
Visibility is necessary, but not sufficient
Rounds did the dashboards, metadata analysis, and query pattern work. Costs still rose, because execution takes time, and time is the scarcest resource on a growing team.
Start where the spend is concentrated
dbt accounted for 60% to 70% of consumption. That’s where savings moved the business.
The best optimization is the one that doesn’t compete with your roadmap
If a solution requires sustained engineering attention, it will lose to product priorities. Automation wins because it runs in parallel.
Savings are great, predictability is better
When you can forecast spend with confidence, you can plan, invest, and move faster.
Want to See What You Could Save?
If you’re running BigQuery at scale and your costs keep climbing even after “doing the right things,” you don’t need another dashboard.
You need a lever that reduces spend without rewriting your platform.
Yuki can help you identify where you have immediate savings potential, starting with the workloads that drive the majority of your compute spend.
