Chain Snowflake dynamic tables into a DAG using target_lag propagation
domain: data-engineering · 6 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Create each dynamic table with CREATE DYNAMIC TABLE ... TARGET_LAG = '<n> seconds|minutes|hours|days' WAREHOUSE = <wh> AS <query>, or TARGET_LAG = DOWNSTREAM to opt out of an independent schedule.
For a DOWNSTREAM table, know that Snowflake refreshes it only as needed to satisfy the shortest target_lag among the tables that consume it — it has no schedule of its own.
Verify every terminal (leaf) table in the DAG uses an explicit numeric target_lag, not DOWNSTREAM, since a DOWNSTREAM table with no consumer never auto-refreshes and Snowflake gives no warning.
Leave REFRESH_MODE = AUTO (the default) unless you have a reason to force FULL or INCREMENTAL — AUTO resolves once at creation and is locked in, not re-evaluated as the query changes.
Check which mode was actually chosen with SHOW DYNAMIC TABLES and inspect the refresh_mode / refresh_mode_reason columns.
To change a locked-in refresh mode, CREATE OR REPLACE (or CREATE OR ALTER) the dynamic table — ALTER DYNAMIC TABLE cannot change it directly.
Known gotchas
The minimum target_lag is 60 seconds — dynamic tables cannot be chained at sub-minute latency.
A DOWNSTREAM table at the end of a chain with no consumer silently never refreshes; this is the most common DAG-authoring mistake with dynamic tables.
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?