How Obie Insurance cut its month-end close from 25 hours to 2 with dbt State and a lake house rebuild

Tyson Doberneck and Matthew Karan, both senior data engineers at Obie Insurance, make up the entire data engineering team at the real estate investment insurance platform. In their session, styled around a Lord of the Rings theme, they walked through how a startup-era data ecosystem of scattered repositories, manual orchestration, and competing sources of truth got rebuilt into a single, reliable dbt project.

Obie was founded in 2017 by brothers Aaron and Ryan Letzeiser and was acquired by The Baldwin Group in 2026. As the company grew past its landlord-insurance roots into homeowners products, its data problems grew with it: logic was duplicated across four repositories with inconsistent version control, and orchestration was split across crontabs, systemd timers, Prefect jobs, and Snowflake tasks, with pipelines running only once a day.

Obie had been an SDF customer before SDF's acquisition by dbt Labs, and the team used that transition, followed quickly by the shift to dbt v2, as the opening to start a greenfield rebuild rather than patch the old system. The team consolidated everything into a single dbt project, moved to a lake house architecture built on Apache Iceberg, and set up catalog-linked databases in Snowflake so new tables are auto-discovered instead of manually recreated.

They also became early design partners for Lake Compute and now run roughly 10% of their project on it, giving them a way to weigh speed against cost instead of being locked into a single compute vendor. On the documentation side, the team self-hosted dbt docs and gave every model a matching YAML file with full column-level descriptions using the dbt-osmosis tool.

They used that same documentation to make their internal Slack AI debugging bot more effective, getting it to roughly 75% of the way toward a fix on pipeline failures. dbt State (dbt's state-aware orchestration) became core to keeping costs down as build frequency went up.

The team shared a real tuning lesson from the talk: setting the evaluate_volatile_sql flag to true on models with clock-driven logic, like an is_active flag comparing an expiry date to the current date, keeps the value correct but forces a rebuild on every run since the underlying function output always changes. Their fix was to move clock-derived columns into a view, which needs no state block, while leaving the rest of the model eligible for reuse.

That kind of tuning is a big part of how the results below became possible. The rebuild shows up directly in the numbers Obie shared: a 99% production build success rate, roughly 40% cost savings from model reuse through dbt State, and a month-end close for the revenue operations team that dropped from over 25 hours to about 2 hours.

In Q&A, the team confirmed they run a single dbt project in a monorepo (with dbt Mesh available if they need to split it later), and that they evaluated the added cost of dbt State against the compute they were saving by not rerunning models unnecessarily, several times a day for their largest workloads, and found it was worth it.

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