Rebuild less, decide more: dbt State in partner delivery
Partner Capabilities: Business Value, Use Cases, & Delivery
October 7, 2026
Session 1: 3:00 PM BST / 10:00 AM EDT Session 2: 4:00 PM PDT / 9:00 AM AEST (next day)
Virtual
David Hrncir
Yuki Misumi
What dbt State actually knows about a project, and how lag_tolerance turns a refresh schedule into a declared decision cadence, model by model, categorically different from state:modified
Why this is a business conversation too: faster decision cadence and lower rebuild cost are a real case for upselling into the full platform
Where to start, and when to walk away: why dev and CI show the difference fastest, plus the pre POC checklist of project patterns that mean this isn't the right fit yet
How Fivetran sync completion becomes the freshness signal governing downstream rebuilds, and where dbt State sits on the path to the rest of the dbt platform
You're all set, [Name].
Registration closed.
Most data teams control cost by running things less often. The refresh schedule your client is on today was almost certainly set by what they could afford, not by how often the business needs to know, and that is a decision latency tax wearing a budget discipline costume. That tax gets collected every time the whole pipeline rebuilds because one small thing changed.
dbt State removes the trade-off. It parses your models semantically, tracks the freshness of the underlying data through the DAG, reasons about which tests actually need to rerun, and rebuilds only what genuinely changed. That is the difference between a refresh schedule set by what you can afford and one set by how often the business actually needs to know.
Who should tune in:
- Delivery consultants and solution architects: if you're the one optimizing a live client implementation, this gives you a change you can make in a dev environment this week and a way to measure it that holds up
- Architects scoping new builds or Core to Platform conversations: dbt State now runs on dbt Core, so it works with clients who've never paid dbt Labs a dollar
- Practice leads and account managers: this is the upsell angle into your own client accounts, not just the technical one
What dbt State actually knows about a project, and how lag_tolerance turns a refresh schedule into a declared decision cadence, model by model, categorically different from state:modified
Why this is a business conversation too: faster decision cadence and lower rebuild cost are a real case for upselling into the full platform
Where to start, and when to walk away: why dev and CI show the difference fastest, plus the pre POC checklist of project patterns that mean this isn't the right fit yet
How Fivetran sync completion becomes the freshness signal governing downstream rebuilds, and where dbt State sits on the path to the rest of the dbt platform
David Hrncir
Yuki Misumi
David Hrncir
Yuki Misumi
Most data teams control cost by running things less often. The refresh schedule your client is on today was almost certainly set by what they could afford, not by how often the business needs to know, and that is a decision latency tax wearing a budget discipline costume. That tax gets collected every time the whole pipeline rebuilds because one small thing changed.
dbt State removes the trade-off. It parses your models semantically, tracks the freshness of the underlying data through the DAG, reasons about which tests actually need to rerun, and rebuilds only what genuinely changed. That is the difference between a refresh schedule set by what you can afford and one set by how often the business actually needs to know.
Who should tune in:
- Delivery consultants and solution architects: if you're the one optimizing a live client implementation, this gives you a change you can make in a dev environment this week and a way to measure it that holds up
- Architects scoping new builds or Core to Platform conversations: dbt State now runs on dbt Core, so it works with clients who've never paid dbt Labs a dollar
- Practice leads and account managers: this is the upsell angle into your own client accounts, not just the technical one