Espresso AI Says Off-Path dbt Models Can Run on Smaller Snowflake Warehouses

The critical path and the slack around it

Every dbt DAG has a critical path, described in the session as the longest unbroken chain of dependencies from the first model to the last. Models outside that chain have slack, meaning they can take longer without delaying the job. According to dbt Labs' write-up of the breakout session, Lerner's core point was that teams should treat that slack as a resource instead of ignoring it.

The warehouse itself does not help here. When dbt sends a job to Snowflake or Databricks, the warehouse has no concept of the DAG. It runs whatever it is told to run, one query at a time, and does not know that some queries are independent of each other and could run in parallel.

"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."

Warehouse sizing as the lever

The mechanism is warehouse size. Snowflake and Databricks SQL warehouses come in t-shirt sizes, and each step up roughly doubles compute cost while rarely doubling speed. The article links this pattern to Amdahl's Law.

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

The difficulty is that the picture keeps changing. As data volume grows, a join that used to scale linearly might stop doing so, and a model that was safely off the critical path last quarter might be on it this quarter. Espresso AI's approach, as described in the session, is to use reinforcement learning rather than manual tuning. It continuously reevaluates warehouse assignment as a project's DAG, data and query patterns shift.

A customer view from Authentic Insurance

Saravana Kumar, CTO of Authentic Insurance, covered the second half of the session. Authentic runs the distribution layer for specialty insurance programs across hospitality, energy, inland marine and construction lines. It has more than 100 partner programs live and reported 15x revenue growth in 2025.

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

Insurance adds its own complications. Claims get re-reserved months after they are first recorded, so data that was correct when loaded can later become wrong, and nothing downstream can safely be treated as append-only. Each new partner program is effectively a new data source arriving mid-project. Because the business is regulated and visible to carriers, a data quality issue is a customer-facing issue.

"We save 40% every quarter because we run Espresso between our dbt models and Snowflake," Kumar said.

What it means for dbt teams

The session's argument is that warehouse spend in dbt projects is not only a matter of query tuning, but of matching compute size to where each model sits in the DAG. For small teams, the appeal described is savings without anyone hand-tuning a single warehouse size.

The 40% figure is a claim from one customer, reported by its CTO, and the source gives no further detail on how it was measured. Still, the session gives teams a concrete starting point: identify the critical path of their jobs, and question whether every other model needs the warehouse size it currently uses.