How WMCHealth cut a 72-minute dbt pipeline down to 5 minutes, with one environment variable

Maksim Romanchuk and Paul Pedrozo, both analytics engineers at WMCHealth, presented at dbt Summit a design pattern for running near real-time operational reporting and full historical analytics from the same business logic, using a single environment variable to switch a model between two execution modes. They framed the talk as a technical walkthrough of a publicly available pattern rather than a case study of confidential data, and noted that any tools named reflect their own environment rather than an endorsement.

WMCHealth runs near real-time operations across nine hospitals on fragmented legacy systems, which meant the team needed two very different things out of the same underlying logic. Near real-time operations refresh every five minutes over active records only, powering dashboards, alerts, and notifications, where speed is everything. Historical analytics refresh nightly over the full dataset for trend analysis and reporting, where completeness is everything.

Before landing on their solution, the team ruled out the obvious fixes. Scaling up the warehouse didn't hold up cost-wise at a five-minute refresh cadence. Building two separate dbt projects risked logic drift, since a metric change made in one copy could easily be forgotten in the other.

And incremental models alone were still too slow against very large tables to hit a near real-time cadence. They needed a design pattern, not more compute.

Their solution: one model, one codebase, two execution modes, switched with a single env_var('ENV_NRT') check. When ENV_NRT is set to '1', the model builds against active records only, as a table materialization, on a five-minute schedule, with a median runtime of 278 seconds. When ENV_NRT defaults to '0', the same model builds against the full dataset overnight as an incremental materialization, with a median runtime of 4,340 seconds.

Downstream, the pattern propagates through the DAG in one of two ways: models that inner join to the narrowed anchor model inherit the smaller scope automatically with no extra code, and models that don't join to the anchor add an explicit WHERE filter checking ENV_NRT via an EXISTS clause. Operationally, both pipelines run from the same codebase and the same CI/CD setup; the environment variable set on each job is the only difference between them.

The results were substantial: a 93.6% runtime reduction, from a median of 4,340 seconds down to 278 seconds, and more than 99% less data processed per run in near real-time mode. That took their live refresh cadence from a 72-minute starting point down to five minutes. Individual staging models showed similarly dramatic reductions between historical and near real-time scope, several in the 99.3% to 99.9% range.

Their takeaways: the fix was a smarter approach to what gets processed and when, not a bigger warehouse. Environment variables are underused in dbt beyond simple feature flags, since they can change how a model behaves at runtime. And inner-join propagation is the cheapest win in the whole pattern, because designing the upstream anchor model correctly lets the narrower scope flow through the DAG for free.

Watch the full session, plus every keynote and breakout from dbt Summit 2026, on demand. Watch dbt Summit 2026 on demand →