Apache Iceberg on Snowflake got a lot simpler in 2026, and dbt's new catalog config is what makes it click

Jeff Skoldberg, a data and analytics consultant at Green Mountain Data Solutions who has spent the last five years working with dbt and Snowflake, opened by admitting he's not an Iceberg expert himself: he started using it only about four months before this talk. That framing was deliberate: his argument was that becoming a user of Apache Iceberg no longer requires becoming an infrastructure expert first, and that 2026 is the year that became true.

The talk centered on two versions of the same underlying problem: a CFO watching the Snowflake bill grow faster than the team, and data scientists who want to work locally in a Jupyter notebook rather than inside a warehouse. Historically, the only cost levers available were tuning levers (smaller warehouses, shorter auto-suspend windows, better clustering), never the option to run a query somewhere else entirely, on the same governed data, for free.

Iceberg, an open table format that lets Parquet files behave like a real table (with inserts, deletes, schema evolution, and time travel), is what makes that possible, since the data lives in the customer's own object storage rather than locked inside a single warehouse's compute.

Skoldberg walked through what changed in 2026 that removed most of the historical setup burden. As recently as six months earlier, using Iceberg on Snowflake meant standing up a separate Polaris catalog account and wiring it to a Snowflake account by hand.

Snowflake's built-in Horizon catalog is now on by default, and Snowflake added external writes directly into Horizon, so teams no longer need a separate tool like Glue just to write data into a governed Iceberg table. On the dbt side, a new catalog_name entry in dbt_project.yaml points to entries in a catalogs.yml file, letting a project define, for example, a raw and a transformed Iceberg catalog with just a handful of config lines.

Skoldberg noted that when Snowflake announced Iceberg writes at Summit 2026, that feature didn't actually work end to end until dbt shipped a set of write-compatibility options to support it, paired with a pull request into DuckDB's own Iceberg library contributed by Anders Swanson at dbt Labs. He called out that Swanson chose to fix that gap upstream in the DuckDB repository rather than only inside dbt itself, which is what let DuckDB read Snowflake-managed Iceberg tables at all.

In a recorded demo, Skoldberg showed a dbt build writing to Snowflake-managed Iceberg tables using temporary, narrowly scoped vended credentials rather than any static AWS setup, then connected DuckDB directly to those same governed tables. The resulting queries returned data instantly and never touched a Snowflake warehouse, meaning zero compute cost, while still respecting Snowflake's row-level access policies and column masking.

He closed with a comparison to DuckLake, a newer open table format: DuckLake is fun to use, he said, but for teams already on Snowflake, Horizon still has the edge because governance, cataloging, and AI tooling like Cortex come built in, whereas DuckLake requires standing up and maintaining a separate Postgres catalog.

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