Snowflake Guide

Snowflake and SQL models: draw the warehouse your repository defines

By the engineer who builds Datadef, from client work on data platforms · Reviewed August 21, 2026

The definition of a Snowflake warehouse is usually spread across three kinds of file in one repository: DDL that creates the schemas and tables, model SQL that builds the layers, and migrations that record how the shape changed. Read together they describe the whole warehouse. Read one at a time in a pull request, they describe nothing. The sync reads them together.

Try it free
7 min readFor data engineers whose warehouse definition lives in SQL files, not in a modelling tool

See it as a diagram

Everything below, as a diagram you can edit. Describe yours and see it in seconds.

145/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

Three SQL classes, three different jobs

The selector treats SQL as three separate classes because the files play different roles. A .sql file under a models/ directory is a transformation and gets the model class, 12 files by default. A .sql file under a migrations directory is a change record and gets the migration class, 6 files. Any other .sql file is DDL or a query and gets the general SQL class, 10 files. Choosing the content focus at the first sync raises those to 18, 8 and 14.

Splitting them means one class cannot starve another. A repo with two hundred migrations and twelve models still gets its models read, because migrations fill only the migration budget. The same protection runs the other way for a repo that is mostly DDL.

Migrations are also the one class sampled from both ends rather than from the top. With the default ceiling of six, three come from the earliest files and three from the latest, so the generator sees the initial schema and the current direction of change without reading anything in between. On a numbered migration folder that is exactly the right pair of snapshots.

How a warehouse repo classifies
  models/marts/fct_orders.sql      -> model class
  models/staging/stg_orders.sql    -> model class
  migrations/0001_init.sql         -> migration class (sampled from the start)
  migrations/0184_add_col.sql      -> migration class (sampled from the end)
  ddl/raw/schemas.sql              -> general SQL class
  snowflake/warehouses.sql         -> general SQL class

What the diagram shows

The generated canvas draws the warehouse as layers with the real names from your files: raw or landing, staging, intermediate, marts or reporting, and the tables inside each. Table nodes carry typed columns with key badges, which is the right idiom for a warehouse and the wrong one for infrastructure, and the canvas uses it here.

Edges come from the SQL itself: the from and join targets in a model, the ref calls where the project uses them, the create table as select in a DDL file. Where a mart is built from three staging tables, the diagram shows three arrows into it, not a decorative layer boundary.

For the finer question, which column feeds which column downstream, the canvas supports column-to-column lineage drawn on top of the same tables. That view is the one people actually need before they alter a column, and it survives a sync because the underlying nodes keep their identity.

No account, no credentials, no query history

Nothing runs against Snowflake. There is no warehouse to spin up, no ACCOUNTADMIN grant to request, no query history to scan, and no information schema to read. The connection is read-only access to the repository, which is what makes this usable during a review, on a client engagement, or on a branch that has never been deployed.

The honest consequence is scope. A source-parsed diagram shows what the repository defines. Objects created by hand in a worksheet and never committed are invisible to it, and that is a fair trade for most teams, because an object nobody committed is an object nobody can review either.

The first sync counts the classified files and proposes a focus with one deterministic sentence. A warehouse repo generally reads as something like: Mostly SQL and database migrations (57 files) with one CI pipeline and no infrastructure code, which argues for the content focus, the one that draws the data path rather than the deployment.

Budgets on a large warehouse

The corpus is bounded: at most 40 files and 250KB, with any single file truncated past 30KB and anything over 400KB skipped outright. A warehouse with four hundred model files is therefore sampled, not exhaustively read, and the sampling is shallow-first then alphabetical so top-level layers win over deeply nested ones.

Two rules decide which of your SQL counts as a model. The directory has to be named models, at any depth, so sql/models/marts/fct_orders.sql qualifies and sql/marts/fct_orders.sql lands in the general SQL class instead. And compiled output never competes for the budget: target, build, dist, and out are skipped by directory name, which is what keeps a dbt-generated copy of every model out of the corpus.

The tree summary keeps that from being a blind spot. Every directory to three levels ships with its file count, so the generator can draw a marts layer labelled with what it holds even when only a few of its files were read. When you want a specific corner drawn in full, sync a branch or tag scoped to it and connect that.

FAQ

Does this connect to Snowflake?

No. It reads the SQL files in the connected repository. There is no Snowflake account, no ACCOUNTADMIN grant to request, no credentials, no warehouse compute to start, and no query history or information schema read, so it works on a branch that has never been deployed and on a client repository you were handed for a review.

How are migrations handled on a repo with hundreds of them?

Migrations are sampled from both ends of the sorted list: half the class ceiling from the earliest files and half from the most recent, so three and three at the default ceiling of six, four and four under the content focus. That gives the generator the initial schema and the current direction of change without spending the whole file budget on the middle of the folder.

Can the diagram show columns and keys?

Yes. Table nodes carry typed columns with key badges, which is the right idiom for a warehouse and the wrong one for infrastructure, and the canvas uses it here. Column-to-column lineage can then be drawn on top of the same tables after generation, and it survives a re-sync because the underlying nodes keep their identity across regenerations.

What happens to objects created manually in a worksheet?

They do not appear. The diagram reflects what the repository declares, so an object created by hand in a worksheet and never committed is invisible to it. That is the same property that makes the approach safe to point at a production warehouse: it reads files, not the account. For most teams the gap is small, because an object nobody committed is an object nobody can review either.

Is there a limit on how much SQL gets read?

Yes, and it is explicit: at most 40 files and 250KB per sync, single files truncated past 30KB, files over 400KB skipped, and a per-class ceiling so one class cannot crowd out the others. The repository tree summary reports the directories and file counts that were not read.