Schema Change Tracking in Snowflake: Why Query History Wins

When most data-lineage tools attempt to track schema changes in Snowflake, they start with the obvious option — reading the current state from INFORMATIONSCHEMA or SNOWFLAKE.ACCOUNTUSAGE. It’s simple. It’s familiar. But it’s not the right foundation for reliable lineage.

The Problem with INFORMATION_SCHEMA Snapshots

Even if you accept the inherent latency, several structural limitations remain:

• it’s not real-time and may lag behind actual changes
• metadata is incomplete — reconstructing full DDL is nearly impossible
• you only see the current state, losing everything that happened between snapshots
• you need broad, future-proof privileges for objects that don’t yet exist

If your lineage or cost analytics rely on this layer, you’re essentially reconstructing history through a keyhole.

The Better Alternative: Querying Snowflake’s QUERY_HISTORY

Instead of guessing what happened by looking at the final state, you can examine the actual source of truth: every CREATE and ALTER statement executed in the account.

This requires parsing, compiling, and applying each statement to a continuously evolving schema model. It’s complex — but the payoff is substantial.

Benefits of Query-History–Driven Schema Tracking:

• full historical evolution of every object, including intermediate states
• up to a year of history, not just from the first snapshot
• accurate CTAS rebuild-cost analytics for any time window
• precise detection of every moment when CTAS or VIEW logic changed
• anomaly detection in CTAS rebuild row counts
• a robust foundation for accurate, column-level lineage

This approach yields the fidelity required for serious data engineering.

How Dwh.dev Implements This

When installed from the Snowflake Marketplace, Dwh.dev reconstructs schema history directly from QUERY_HISTORY, giving you a complete and trustworthy audit of your Snowflake metadata.

• no external services
• works even on Standard Edition (no dependency on ACCESS_HISTORY)
• all processing stays entirely within your Snowflake account
• full-spectrum lineage across all Snowflake object types — not just TABLEs and VIEWs