Column-level lineagefor Snowflake and beyond
Callisto parses the SQL of each job that writes to Snowflake into column-level lineage, so every pull request shows the exact columns a change reaches, inside the warehouse and beyond it.
Selected column
stg_orders.order_total
SQL model · NUMBERUpstream · 1
Downstream · 3
01 · The problem
Table-level lineage names the tables
a change touches and stops there
A renamed or retyped column looks the same to every table downstream. Nobody can say which columns read it until something breaks.
Tables reached by order_total
The table graph
Shows which tables a change reaches. A renamed column and an untouched one look the same to every table downstream.
The pull request
Shows the line that changed. It does not say which columns in other models read order_total.
Reads order_total
The column readers
Nobody has listed them. Finding out means opening each downstream model and reading its SQL.
02 · Who it’s for
Three readers ask three questions
of the same lineage
Engineers, platform leads and architects each ask something different of the same graph.
Asks
“Which columns read the one I am about to rename?”
Keeps them up
Merging something that breaks a dashboard they have never heard of, then being the person who renamed the column.
What they get
The downstream columns across platforms, with parsed and inferred edges marked, in the pull request thread.
Downstream of order_total
revenue_daily.net_revenuerevenue_export.net_revenuefinance_weekly_job.net_revenueAsks
“Which pull requests reach a column that other teams use?”
Keeps them up
Velocity going up while stability goes down, with no way to prove which change caused what.
What they get
The affected columns for every pull request in one report, before anyone approves the merge.
Asks
“What is in our estate that nobody has mapped?”
Keeps them up
Committing to a migration plan built on an incomplete map, then finding a dependency after the cutover.
What they get
Column-level lineage across Snowflake and the rest of the estate, plus the systems Callisto sees but does not yet cover.
03 · How the graph is built
Four steps from Snowflake SQL
to column-level lineage
Callisto reads the jobs that write to Snowflake and marks which links it parsed and which it inferred.
Step 01
Read the tables and jobs in Snowflake
Callisto reads Snowflake metadata and the jobs that write to it, with OpenLineage data and Avro on S3, into one cross-platform catalog.
Step 02
Parse each job’s SQL into column edges
Callisto parses the SQL of each job and traces every output column to the input columns it reads, with no manual curation.
Step 03
Mark the edges it cannot confirm
Edges matched by name are marked inferred and drawn dashed, so you can see which links were parsed and which were inferred.
Step 04
Flag the systems it is not covering
Namespaces that appear in OpenLineage events without a mapping show up as not yet mapped, so you can see where coverage stops.
04 · The difference
From which tables change
to which columns break
Table-level lineage tells you which tables a change touches. Callisto names the columns inside them that read it.
4 tables · 0 columns
Columns that read stg_orders.order_total
Three downstream columns read it. The other columns in these tables are unaffected.
1 report · columns and systems
05 · How it works
Open a pull request,
read the report in the thread
Step 01
Open a pull request
Callisto starts from the pull request your team already opens.
- A GitHub webhook starts the analysis
- GitHub is the only source control system supported today
Step 02
Trace the columns
The agent walks column lineage from every column the pull request touches, across platforms.
- Column-level lineage across platforms
- Parsed edges and inferred edges, kept apart
- Systems it has not mapped, listed as gaps
3 downstream columns across 3 assets. 1 of them is inferred.
Step 03
Read the report
The impact report lands in the pull request thread. You can also ask in Slack, web chat or the CLI.
- Affected columns, with inferred edges marked
- Columns in other systems, not only in Snowflake
- Read-only: it posts comments and changes nothing
06 · Is this you?
Where it fits, and where it doesn’t
Fits
- Snowflake, plus at least two other platforms.
- Something consumes data outside the warehouse: BI, reverse-ETL, notebooks or applications.
- Airflow, Dagster or similar, and more than one team touching the same tables.
- Pipeline code reviewed in GitHub pull requests.
- Engineers using AI coding tools on pipeline code.
Not a fit
- Single-platform shops.
- Small teams where one person holds the whole picture.
- Teams on GitLab, Bitbucket or Azure DevOps. The pull request flow is GitHub only today.
- Organisations that prohibit AI tooling outright. A local-model story is coming.
- Anyone looking for a data catalog, a glossary or data quality monitoring. Those are different products.
Callisto reports which columns a change will affect. It does not apply the fix: it is read-only outside the comments it posts.
For consultancies and SIs →Faster estate discovery, and a tool the client keeps using after handover.07 · FAQ
Questions teams ask before they try it
Callisto parses the SQL of each job that reads from and writes to your Snowflake tables and traces every output column back to the input columns it reads. It combines that with OpenLineage data and Avro on S3 in one cross-platform catalog, so a pull request shows the columns a change reaches inside Snowflake and beyond it.
No. Lineage comes from parsing each job’s SQL, with no manual curation.
Across the platforms Callisto reads, including Avro on S3 and jobs reported through OpenLineage. Namespaces it sees but doesn’t cover are listed as not yet mapped.
Edges matched by name are marked inferred and drawn dashed, so a reviewer can tell a parsed link from a guess. Systems Callisto can’t read yet show as not mapped.
They appear in the report as not mapped, so you can see where coverage stops instead of assuming there are no readers.
No. Callisto reports what a change will affect. It doesn’t apply the fix: it is read-only outside the comments it posts.
GitHub only today. The pull request flow doesn’t support GitLab, Bitbucket or Azure DevOps yet.
In the pull request thread where the report is posted. You can also ask in Slack, web chat or the CLI.
Join the waitlist
Bring one pull request
Thirty minutes, your estate, one change you have shipped. Callisto traces the columns with you and changes nothing.
0–10 min
ConnectGitHub, Snowflake and your OpenLineage data, read-only.10–20 min
Pick one pull requestA change to a column, a job or a model.20–30 min
Read the report togetherAffected columns, inferred edges and gaps in coverage.
Single-tenant deployment. Callisto reads metadata, lineage and run history. It is read-only outside the comments it posts.