How dbt Labs and Fivetran are moving dbt workloads onto the data lake, model by model

In this session (delivered, memorably, with both speakers dressed as ducks), Russell Christopher, senior director of product strategy at dbt Labs, and Casey Karst of Fivetran, who previously owned the dbt adapter at Dremio and now works on Fivetran's managed data lake, made the case that data lakes built on open table formats are the next evolution of the data stack, and that teams can adopt them in small steps rather than one large migration. Christopher opened by naming the problem with today's modern data stack: it looks like it separates storage from compute, but in practice most teams write their data directly into a proprietary format owned by a single compute engine, which drives up cost, limits which engine can do which job, and makes future migrations painful. He described his own past data migrations as taking three to nine months and carrying real risk, calling them "death marches."

The alternative the session proposed centers on Apache Iceberg as an open table format sitting at the middle of the architecture, exposed through an Iceberg REST catalog (dbt Labs and Fivetran support Apache Polaris), so that multiple engines, Snowflake, Databricks, BigQuery, or others, can read and write the same data without copying it. Karst then demoed how Fivetran handles this today: setting up a destination on Fivetran's managed data lake only asks a handful of questions (storage provider, bucket, path, and how many Iceberg snapshots to retain for time travel), with sensible defaults for everything else, including catalog integration with AWS Glue or Databricks Unity Catalog. He also demoed a newer "Move" capability that migrates an existing Snowflake-native table to an Iceberg table in place, preserving the same table namespace so dependent dbt models and BI dashboards keep working without any changes, completing in a couple of minutes in the live demo.

Because Fivetran was already writing and then re-loading that data through Snowflake, moving it to the managed lake also cut roughly 15 to 20 percent off the Snowflake compute bill for that workload, at no extra cost, since Fivetran already charged the same monthly active rows pricing.

Christopher then extended the idea to the transformation layer with a concept Fivetran calls Lake Compute: since a dbt project's individual models don't all need the same compute, some are simple filters, casts, or renames ("a trip to the mailbox," in his framing), while others involve heavy joins or use warehouse-native AI functions ("a blizzard," needing the SUV). Lake Compute lets a team move specific, low-complexity dbt models off premium warehouse compute and onto cheaper lake-native compute, model by model, without restructuring the DAG or the project. Christopher shared directional (not precise) numbers suggesting ingestion and transformation together account for roughly 75 percent of a typical data stack's compute spend, and that this approach targets exactly that spend without changing what analysts or BI tools see downstream, since the gold layer serving those consumers stays put.

The session closed by distinguishing the reference architecture (an open lake built on open table formats and open catalog interfaces, which preserves choice of engine) from the build-versus-buy decision on top of it: teams comfortable with open source can assemble their own lake stack, while teams that want it managed can use Fivetran's data lake for ingestion and Lake Compute for targeted transformation savings, without giving up the open standards underneath. Christopher and Karst pointed attendees to a follow-up roundtable session on Open Data Infrastructure later that day for a deeper, more informal discussion.

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