# 16M Rows, Precisely Orchestrated > How one scheduled root and a Snowflake task graph replaced guessed wait times — and kept incomplete refreshes from reaching dashboards. - Author: Paul Yu - Role: Senior Analytics Engineer - Employer: Viral Nation - Year: 2026 - Theme: Reliability - Human article: [https://paul-yu.com/case-studies/warehouse-pipeline-orchestration](https://paul-yu.com/case-studies/warehouse-pipeline-orchestration) - Structured data: [https://paul-yu.com/agent/case-studies/warehouse-pipeline-orchestration.json](https://paul-yu.com/agent/case-studies/warehouse-pipeline-orchestration.json) ## Evidence | Value | Measure | Evidence level | | --- | --- | --- | | 16.0M | observation rows served | Measured | | 298 | successful task runs | Measured | | 13 | orchestrated tasks | Measured | | 1 graph | declared dependency order | Repository backed | ## Situation Dozens of related warehouse tables finished at different times. A late source or an early downstream refresh could leave reports stale, incomplete, or mixed until someone re-ran the right tables by hand. ## Task Make refresh order systematic. The pipeline needed to wait for real dependencies instead of assuming each table would finish by a guessed time. ## Action I disabled each dynamic table's independent scheduler and built a Snowflake task graph. One scheduled root starts the core run. Child tasks cascade only after their declared parents succeed, and independent branches run in parallel. ## Result Thirteen tasks recorded 298 successful runs while serving 16.0 million post-observation rows through the reporting stack. Incomplete refreshes no longer raced ahead of their parents. ## System flow Sources ready → Dimensions + facts → Relationships → Reporting marts ## Technical notes ### Directed acyclic graph A DAG maps each job to the jobs it depends on. An upstream table runs before anything that needs it, and the graph cannot loop back on itself. ### Orchestrator-managed dynamic tables Dynamic tables store prepared query results, while Snowflake tasks own the refresh timing and order. This avoids several schedulers competing over one pipeline. ### Run history The history shows when each task ran and whether it finished. The team can inspect the schedule instead of treating it as a hidden background process. ## Ownership I built and ran the serving-layer tasks, their dependency order, the schedules, and the refresh checks. ## Limitations The task history records 298 successful runs. It cannot tell us whether every source value was correct on every run. Row count measures table scale, not how many rows changed per run. ## Takeaway One root starts the work. The graph decides what follows. Reports stop landing half-ready because no required child can race ahead of its parent. ## Tools Snowflake Tasks, Dynamic tables, SQL, DAG orchestration, Refresh history