Snowflake schema diagram automation: ACCOUNT_USAGE has the object graph, mind its lag

Snowflake gives you two ways to read its own metadata, and they disagree on scope and freshness. SNOWFLAKE.ACCOUNT_USAGE covers the whole account from one place, keeps rows for dropped objects with a DELETED timestamp, and lags: up to about two hours for most views, and anywhere from 45 minutes to three hours across the full set. Each database's INFORMATION_SCHEMA is the opposite: real time and lag-free, but scoped to one database, showing only objects your role can see, with no memory of anything dropped.

For a whole-account map, ACCOUNT_USAGE is the right base: one connection, every database, history included. For verifying that an object exists right now, SHOW OBJECTS IN DATABASE or an INFORMATION_SCHEMA query is the check. A regeneration loop typically uses both: ACCOUNT_USAGE for the graph, a SHOW pass to confirm the freshly deployed objects the lagging views have not caught up to yet.

The edges of the diagram, which view reads which table, which materialized view is built on what, live in SNOWFLAKE.ACCOUNT_USAGE.OBJECT_DEPENDENCIES as referencing and referenced object pairs. One query returns the dependency graph for the whole account, and Snowflake documents this particular view's latency at up to three hours, the slow end of the ACCOUNT_USAGE range, which is worth knowing before you wire it into automation.

-- Edges: which objects are built on which (latency up to ~3 hours)
SELECT referencing_database, referencing_schema, referencing_object_name,
       referenced_database,  referenced_schema,  referenced_object_name
FROM snowflake.account_usage.object_dependencies;

-- Nodes that exist right now, no lag, one database at a time
SHOW OBJECTS IN DATABASE analytics;

Most Snowflake estates are layered on purpose: a RAW database for landed data, STAGING for cleaned models, ANALYTICS for marts, or the dbt-style equivalent inside one database with schemas per layer. Map databases to top-level zones and schemas to groups inside them and the diagram inherits the architecture your team already enforces with grants and naming.

Warehouses are the one Snowflake object class to think twice about. They are compute, not storage, and they hold no data edges. Draw them only when the diagram is answering who pays for what or what runs where; on a pure object map they are noise.

The first diagram is a paste away: the Snowflake diagram generator turns a described or exported structure into an editable canvas. Keeping it current is where the metadata queries earn their keep. An agent connected to Datadef's MCP server, registry name io.datadef/mcp, can run the two queries above and update the diagram in place: schedule that agent from CI cron, or invoke it as the last step of the pipeline that changes the warehouse, a dbt run's completion being the natural hook. Datadef does not connect to Snowflake or poll it; the agent you run does the reading, with a Datadef API key from settings, on paid plans.

The lag shapes the schedule. A redraw fired ten minutes after a deploy will not see the new views in OBJECT_DEPENDENCIES yet. Either delay the regeneration past the latency window, or have the deploying pipeline tell the agent what changed, which a dbt manifest already knows, and let ACCOUNT_USAGE confirm on the next scheduled pass.

OBJECT_DEPENDENCIES records dependencies between object definitions. It does not know that a BI dashboard queries a mart table every morning, because ad hoc reads are usage, not structure; read-side lineage is a different problem with different sources, covered from the catalog angle in keeping a data dictionary in sync.

And the standing limits of the surface: a diagram embedded live in a wiki or README requires the project shared public, so a confidential warehouse layout may belong in an exported image instead. Datadef also stays out of your prose; it keeps the object map current, not the model documentation around it.

• Snowflake diagram generator
• Snowflake architecture guide
• Keep a data dictionary in sync with the schema
• The Datadef MCP diagram server