Callisto traces every column from raw sources through data marts and semantic models, then shows on the pull request what a change touches.
analytics.orders · 5 readers checked
Upstream
Snowflake
Downstream
customer_idAirflowcustomer_idPostgrescustomer_idRawcustomer_iddbtcustomer_idPR #517customer_keyrenamedcustomer_keyfixedcustomer_idAirflowcustomer_idTableaucustomer_idReverse-ETLcustomer_idNotebookWarehouse lineage ends here
Warehouse lineage ends here
01 · The problem
Snowflake maps its tables. dbt maps its models. Airflow maps its tasks. The edges between them belong to no one, and that is where a rename that passes every test still breaks something.
Finance dashboard
Opened daily by 12 viewers
Daily revenue
What Snowflake sees
select customer_id from analytics.orders1 query · 06:00BI extracts
The warehouse sees a 06:00 query, not a Tableau dashboard with twelve daily viewers.
orders_to_crm
Every 15 min
customer_idorder_dateamountproduct_categoryCRM
Customer account
customer_id→ Account IDamount→ Lifetime valueSync failed: field customer_id not found
Reverse-ETL
Rename one of its four columns and the sync fails in a tool your data team never opens.
features = spark.table( "analytics.orders")df = features.select( "customer_id", "amount")Notebooks
It reads customer_id by name, its author has left, and it breaks the first Monday after merge.
02 · Who it’s for
An engineer asks who reads a column. A platform lead asks what depends on the warehouse that nobody owns. Both answers cross platforms.
Data engineer
“Who else reads this column?”
Keeps them up
A rename that passes every dbt test and still breaks a Tableau extract, a CRM sync, or a notebook nobody has opened in a year.
What they get
Every reader of the column, in every system, on the PR. Keep an alias, or ping the owner before merge.
Your PR #517 renames analytics.orders.customer_id.
Four readers outside dbt still select it:
daily_rollupTableau · revenue_dailyorders_to_crmchurn_features (inferred)Kept customer_id as an alias for one release. Re-check shows 0 breaking.
Data platform lead
“What breaks if we
retire this table?”
Keeps them up
Each team's tool shows its own slice. When something downstream breaks, finding the change behind it means joining four systems by hand.
What they get
One graph across the stack, checked on every change, with a record of which PR reached which downstream system.
Readers of analytics.orders5 readers · 4 systems
dbtfct_revenueparsed
Airflowdaily_rollupparsed
Tableaurevenue_dailyparsed
Reverse-ETLorders_to_crmparsed
Notebookchurn_features.ipynbinferred
Warehouse lineage shows 1 of these 5 readers.
03 · How Callisto closes the gap
One revenue calculation, followed through every system that reads it, and posted as one comment before merge.
What the PR shows
models/marts/orders.sqlPR #517 · priya.kselectorder_id,customer_id,customer_id as customer_key,order_ts,amountfrom analytics.stg_ordersPR checks
Compiles
dbt tests pass
Warehouse lineage flags 1 model
What Callisto posts
customer_id is renamed. Four readers outside dbt still select it.
| Reader | Status |
|---|---|
|
dbt · already updated in this PR |
fixed |
|
Airflow · parsed from DAG code |
breaks |
|
Tableau · extract field customer_id no longer exists |
breaks |
|
Reverse-ETL · field map customer_id → Account ID |
breaks |
|
Notebook · name-matched, marked inferred |
inferred |
Postgres
app.ordersAirflow
load_ordersSnowflake
raw.ordersCallisto follows a column back to the app table and the Airflow task that loads it, so a change to the source shows up on the PR too.
analytics.orders
order_id
customer_idrenamed
order_ts
amount
orders_to_crmbreaks
customer_id→ Account ID
Edges are parsed from SQL, DAG code and sync definitions down to the column, so a rename reaches only the readers that select it.
Edges into analytics.orders
revenue_dailyparsed
churn_features.ipynbinferred
4parsed
1inferred
Where no connector or lineage event covers a tool, name-matched edges are marked inferred. A reviewer can tell a fact from a guess.
04 · What it reads
Upstream sources, the warehouse and its transforms, and the tools that read from it. Each edge is labelled with how it was found.
Read-only, except for the comments it posts on pull requests.
Sources
analytics.orders · customer_id
Upstream
AirflowDAG code and task SQLparsed
OpenLineage ProvidersRun events from any emitterreported
ETL PipelinesVia the load job that reads themparsed
Catchessource changes that reach the warehouse a day later.
Warehouse & transform
SnowflakeQuery history and view SQLparsed
dbtManifest and compiled SQLparsed
GitHubPull request diffstrigger
Catchesmodel and view breaks, column by column.
Downstream
Tableau extractsExtract and data-source queriesparsed
Reverse-ETL syncsSync models and field mapsparsed
Scheduled notebooksTable references in codeinferred
Catchesthe dashboard, sync or notebook no one listed.
Tags show how each edge was found.
05 · Compared
Each maps its own platform well. None follows a column across all of them, and none checks the pull request before merge.
| Question | Warehouse-native lineage | dbt lineage | Data catalogs | Callisto |
|---|---|---|---|---|
| What does it map? | Tables and views inside one warehouse | Models and sources in one dbt project | Assets its connectors have ingested | Every hop, from source table to dashboard |
| Upstream of the warehouse? | Stops at the first table | Declared sources only | Where a connector exists | App databases, Airflow tasks, lineage events |
| Downstream of the warehouse? | Sees queries, not the tools behind them | Exposures, if someone declared them | Where a connector exists | BI extracts, reverse-ETL syncs, notebooks |
| When do you see it? | After the change is deployed | In the project docs | When someone opens the catalog | On the pull request, before merge |
Each tool is right about its own platform. The breaks happen in the edges between them.
06 · FAQ
What it reads, how it finds edges between tools, and what it changes.
It is lineage that follows a column across tools, not just inside one. Callisto traces it from the app database and the job that loads it, through Snowflake and dbt, into the BI extracts, reverse-ETL syncs and notebooks that read it.
Join waitlist
Thirty minutes, your estate, one open PR. Callisto traces it past the warehouse, posts a comment, and changes nothing else.
Single-tenant deployment. Callisto reads metadata, lineage and run history. It is read-only outside the comments it posts.
0–10 min
10–20 min
20–30 min
Readers of analytics.orders.customer_id,
every system