Why most of your dbt models aren't in a hurry, and what that's worth in Snowflake credits

In a dbt Summit 2026 breakout session, Ben Lerner, CEO of Espresso AI, opened with a claim that sounds counterintuitive until you look at an actual dbt DAG: most of the models in it don't matter for how long your job takes to finish.

Every dbt DAG has a critical path, the longest unbroken chain of dependencies from the first model to the last. Everything not on that path has slack, and Lerner's core story was about what happens once a team starts treating that slack as a resource instead of ignoring it.

The part of the DAG nobody's watching

When dbt sends a job to Snowflake or Databricks, the warehouse itself has no concept of the DAG. It just runs whatever it's told to run, one query at a time, unaware that four of those queries have no dependency on each other and could run in parallel instead.

"Most of the stuff in your DAG is not on the critical path," Lerner said. "It is not going to make your job run longer overall. And we can use this information to save money, because running things slower can be cheaper."

The mechanism is warehouse sizing. Snowflake and Databricks SQL warehouses come in t-shirt sizes, and each step up roughly doubles compute cost while rarely doubling speed, a pattern familiar to anyone who's read up on Amdahl's Law.

Lerner's guidance: find the critical path, and aggressively downsize everything that isn't on it. A short query that finishes in five seconds is unlikely to be load-bearing for the job's overall runtime, so there's little reason to run it on anything larger than the smallest warehouse available.

The harder problem is that this calculus changes constantly. As data volume grows, a join that used to scale linearly might not anymore, and a model that was safely off the critical path last quarter might not be this quarter. Espresso AI's approach is to model this with reinforcement learning rather than manual tuning, continuously reevaluating warehouse assignment as a project's DAG, data, and query patterns shift.

What that looks like inside an actual dbt project

Saravana Kumar, CTO of Authentic Insurance, took the second half of the session to walk through what this looks like as a customer rather than a vendor pitch. Authentic runs the distribution layer for specialty insurance programs, spanning hospitality, energy, inland marine, and construction lines, with more than 100 partner programs live and 15x revenue growth in 2025.

The company runs on a small data team, supporting a workforce of about 70 people, with dbt driving a consistent semantic layer between an OLTP layer on DynamoDB and an OLAP layer on Snowflake for analytical query flexibility. Espresso sits between the two, watching dbt's model runs and routing them to the right-sized warehouse automatically.

Insurance adds its own wrinkles on top of the standard cost problem. Claims get re-reserved months after they're first recorded, which means data that was correct when it loaded can become wrong later, so nothing downstream can safely be treated as append-only. Every new partner program is effectively a new data source arriving mid-project, and because the business is regulated and externally visible to carriers, a data quality issue is a customer-facing issue, not an internal one.

"We save 40% every quarter because we run Espresso between our dbt models and Snowflake," Kumar said. For a data team of a handful of people supporting dozens of live insurance programs, that's savings realized without anyone having to hand-tune a single warehouse size.

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