← Back to list

Your Warehouse Bill Has a Scheduling Problem. Orchestra Has a Fix.

Most data teams run dbt on a schedule. Every hour, every six hours, once a day … pick your cadence, set the cron job, and walk away. It’s…

South Shore Analytics · 2026-04-29 17:09 · 5 claps · 4.0 min read
#data-orchestration #analytics #data-analytics #data-engineering #data-pipeline
Open on Medium ↗
Wiki topics: GRW · Growth & Analytics 🔧 · Data Engineering

Your Warehouse Bill Has a Scheduling Problem. Orchestra Has a Fix.

Most data teams run dbt on a schedule. Every hour, every six hours, once a day … pick your cadence, set the cron job, and walk away. It’s simple, it’s predictable, and it works right up until someone asks why the warehouse bill tripled last quarter while the number of actual data consumers stayed flat.

The uncomfortable truth is that the majority of scheduled dbt runs don’t need to happen. The upstream data hasn’t changed, the models haven’t been modified, and the output is byte-for-byte identical to what was already sitting in the warehouse. You rebuilt the whole house because the mailman came, and he didn’t even have anything for you.

Now, the fair pushback here is that fixed schedules are genuinely useful. They’re easy to reason about. Debugging is straightforward because you know exactly when things ran and in what order. For teams that are early in their data maturity or operating with a small number of models, the overhead of rebuilding everything on a timer is negligible. Nobody’s losing sleep over an unnecessary dbt run that takes four minutes.

But that calculus changes fast. As your model count grows, as dependencies get more complex, and as warehouse compute costs start showing up in quarterly reviews, the gap between “rebuild everything on a timer” and “rebuild only what actually needs rebuilding” becomes the kind of line item that gets people’s attention.

What State-Aware Orchestration Actually Means

This is the core idea behind state-aware orchestration, and it’s simpler than the name suggests. Instead of asking “is it 6am? Time to run dbt,” your orchestrator asks a different question: “has anything actually changed since the last run?” It compares the current state of your project (model code, upstream data freshness, dependency status) against the previous run and only executes the models that have a reason to execute. Everything else gets skipped.

dbt itself has supported pieces of this for a while. The state:modified selector and related flags let you compare your project against a prior manifest and run only what's changed. The dbt documentation covers the mechanics well. But in practice, most teams using dbt Core have found that wiring up state-based selection into a production-grade orchestration workflow is more plumbing than they bargained for. You need somewhere to store the manifest artifacts, logic to handle the comparison, and a scheduler smart enough to act on the results. It's all solvable, but it's also the kind of infrastructure work that tends to sit on the backlog indefinitely.

Where Orchestra Fits

Orchestra’s State-Aware Orchestration (SAO) takes that concept and makes it the default behavior rather than an advanced configuration exercise. SAO is a purpose-built package for dbt Core that stores model state, compares it across runs, and handles the orchestration logic so you don’t have to. You declare when models should be fresh, and Orchestra figures out which ones actually need to run to make that true.

The practical result is that teams move from manually tagging models and managing selectors to writing declarative freshness schedules. Orchestra’s build_after configurations and customizable freshness checks mean data is only processed when it arrives. Models that would have run unnecessarily get skipped, which directly reduces both compute costs and build times.

What makes this interesting beyond just “fewer runs” is that Orchestra applies state awareness across the entire pipeline, not just the dbt layer. Ingestion, transformation, testing, and downstream systems like dashboards or reverse ETL all participate in the same state-aware graph. When an ingestion job finishes, it can trigger dbt. When dbt updates models, it can trigger tests and dashboard refreshes. When nothing changed upstream, everything downstream stays quiet. The pipeline becomes reactive instead of reflexive.

Failure handling improves meaningfully too. In a traditional setup, a failure in one task tends to cascade: the whole pipeline breaks and someone has to untangle what ran, what didn’t, and what’s safe to retry. With state awareness, Orchestra can isolate exactly where a failure occurred, retry only the affected components, and prevent downstream processes from running on incomplete data. Pipelines become more resilient without requiring more engineering effort to make them so.

Why We Partnered with Orchestra

South Shore Analytics has been working with Orchestra for a while now, and the results have been consistently superb. We’re excited to announce that our relationship is taking the next step: SSA has been selected as one of the approved SAO Experts for Orchestra State-Aware Orchestration!

The reason is straightforward. The teams we work with keep running into the same pattern: they’ve outgrown scheduled dbt runs, they know state-aware orchestration is the right move, but the gap between “understanding the concept” and “having it running in production” is wider than it should be. Orchestra closes that gap faster than anything else we’ve seen, and the teams that have made the switch have simplified their architecture, reduced their build times, and spent less time debugging pipeline failures. That’s the kind of outcome worth putting our name next to.

For teams running dbt Core specifically, Orchestra’s SAO means you don’t need to manually tag models or manage complex selectors. You tell Orchestra when your data should be fresh, and it handles the dependency graph from there. For teams where cost and efficiency matter (which, increasingly, is everyone), the “only process what changed” model is a meaningful improvement over the “run everything and hope it’s fast enough” alternative.

If This Sounds Relevant

If you’re curious about whether state-aware orchestration fits your stack, here are a few places to start. Orchestra’s SAO tutorial walks through the technical setup. You can try Orchestra directly with a free tier.

And if you’d rather talk through it with someone who’s implemented this across multiple teams and can give you an honest read on whether it’s the right fit for your situation, that’s exactly the kind of conversation we have at South Shore. Reach out and we’ll take a look!

Orchestra #dbt #StateAwareOrchestration #SouthShoreAnalytics


메타데이터
post_id
f1c95e5ffb1f
slug
your-warehouse-bill-has-a-scheduling-problem-orchestra-has-a-fix-f1c95e5ffb1f
url
https://medium.com/@southshoreanalytics/your-warehouse-bill-has-a-scheduling-problem-orchestra-has-a-fix-f1c95e5ffb1f
canonical_url
https://medium.com/@southshoreanalytics/your-warehouse-bill-has-a-scheduling-problem-orchestra-has-a-fix-f1c95e5ffb1f
author_url
https://medium.com/@southshoreanalytics
status
ok
fetched_at
2026-06-09 15:37:30