How Virgin Media O2 cut compute costs 30% by giving dbt a memory

In a dbt Summit 2026 breakout session, two analytics engineers from Virgin Media O2, Mel Simpson and Gorgon Curzon, walked through what happens when a dbt project outgrows the tools built to run it. The UK's largest converged telecoms network runs a single-tenant dbt platform instance on BigQuery, serving 42 million customers across mobile, broadband, and TV.

That instance supports more than 300 dbt users across 100-plus federated projects and 5,500-plus models. The core story is what happens once a dbt deployment reaches enterprise scale, and what a team does when the platform that once felt fast enough starts working against its own developers.

The bill nobody puts on a spreadsheet

Every job run across the team's UAT and production environments was stateless. Gordon, head of analytics engineering, described what that meant for a single day.

"I'm sitting there watching the reload button refresh itself every 30 seconds, until it finally finishes," Gordon said, describing the wait for the team's largest job, an over 1,400-model run they call the Nutcracker job, to complete.

A single-column change in one staging model could force the whole project to reparse, recompile, and rerun, sometimes twice, once in UAT and once in production. Gordon's team called this the "redundant build cycle" problem: developer velocity slowing to a crawl as engineers waited on the same rebuilds over and over.

Simpson, lead analytics engineer, broke down where the money actually went. Compute was the obvious cost: full DAG builds for the smallest changes, with multiple jobs rebuilding the same models within the same hour.

"There's one that nobody ever puts on the spreadsheets: developer costs," Simpson said. "Hours lost to context switching and rework from errors that should have been caught earlier."

Then there was opportunity cost. Every hour spent waiting on a pipeline was an hour analysts weren't delivering insight, and every slow iteration was a decision that didn't get made.

An engine built to remember what it already did

The team's answer was dbt v2, a ground-up rewrite of the dbt engine in Rust, paired with dbt State, the feature that lets dbt skip or reuse work instead of rebuilding every node on every run. Mel described dbt v2 as an entirely new orchestration engine, one that parses and understands SQL at the column level, rather than a routine version upgrade to the existing runtime.

The team tested dbt State against the Nutcracker job directly. Without state, the job's 1,424 models took roughly 1 hour 53 minutes to complete; with state enabled, the same job finished in about 1 hour 13 minutes, a 35% improvement.

Of those 1,424 models, 1,392 reran and 32 were reused outright, skipped because dbt recognized nothing upstream had changed. BigQuery slot consumption on the job dropped from roughly 4,500 to 3,400 slots per hour, a reduction that mattered most at peak time, when every team is competing for the same reservation.

"dbt v2 is actually giving us back 25% of unnecessary processing that we're seeing in our systems at the moment for this run," Simpson said. On simple on-demand BigQuery pricing, that translated to roughly $96 saved on a single Nutcracker run, a 25% cost reduction on that job alone.

The numbers behind the migration

Across the full migration, Virgin Media O2 validated a set of enterprise-scale results: roughly 30% lower compute costs, exceeding the team's original 20% target, along with about 35% faster model run times across all jobs and a 40% improvement on the largest job specifically. CI/CD pipeline dependency dropped by about 25%, and developers reported roughly 35% less time spent waiting on builds.

None of this came free. Getting to a clean static analysis baseline meant working through years of accumulated technical debt: models nobody had touched in years, ambiguous SQL, and third-party packages that hadn't yet been updated for dbt v2.

The team is still working through some open items, including aligning dbt v2 with custom FinOps configurations that automatically route jobs between BigQuery's on-demand and reservation pricing models. That alignment protects millions of dollars a year in savings, which is why the team called it non-negotiable before a full production rollout.

What's next is column-level static analysis, plus early experiments connecting the dbt MCP server to AI workflows that can already diagnose job failures in minutes instead of hours. The team framed the whole migration as a shift from reactive firefighting to proactive engineering, with the human impact, less time waiting, more time building, as important to them as the cost savings on the slide.

Watch every keynote and breakout from dbt Summit 2026 on demand. Watch dbt Summit 2026 on demand →