Trino and Presto Data Lineage: Column Lineage Across Federated SQL

Trino data lineage is the column-level map of how data flows through Trino (and Presto) SQL: which source columns in which catalogs feed each output column, and through which joins, functions, and filters. Because Trino is a federated query engine, a single statement can read from hive, postgresql, and iceberg catalogs at once — so accurate lineage must resolve every column to its fully-qualified catalog.schema.table.column identity, not just a table name. Gudu SQLFlow does this with dedicated dialect parsers for both Trino and Presto.

Why federation makes Trino data lineage harder

In a conventional warehouse, lineage lives inside one database: every table in a query belongs to the same system, and a two-part name like sales.orders is unambiguous. Trino breaks that assumption. Its whole purpose is to join data across systems — a Hive table on S3, a PostgreSQL operational database, and an Iceberg lakehouse table can all appear in the same SELECT.

That creates three problems most lineage tools handle badly:

• Name collisions across catalogs. hive.sales.orders and postgresql.sales.orders are different physical tables in different systems. Lineage that drops the catalog qualifier merges them into one node — and every downstream impact analysis built on it is wrong.
• Partial qualification. Real queries rarely spell out three-part names everywhere. They rely on the session’s default catalog and schema, aliases, and USE statements. The resolver has to reconstruct the full identity of every column reference from that context.
• Cross-system boundaries in one statement. An INSERT INTO iceberg.... that selects from Hive and PostgreSQL is a data movement between three systems expressed in one statement. Table-level lineage tells you the systems touched; only column-level lineage tells you which PostgreSQL column ended up in which Iceberg column.

SQLFlow’s semantic resolver keeps the full catalog.schema.table.column path on every node in the lineage graph, so cross-catalog columns stay distinct and traceable end to end.

A worked example: Iceberg target, Hive and PostgreSQL sources

Here is a typical federated write — building a customer-value table in an Iceberg catalog from an operational PostgreSQL database joined to Hive order history:

INSERT INTO iceberg.analytics.customer_value
SELECT
    c.customer_id,
    lower(c.email)        AS email,
    sum(o.order_total)    AS lifetime_value,
    count(*)              AS order_count
FROM postgresql.crm.customers AS c
JOIN hive.sales.orders        AS o
  ON c.customer_id = o.customer_id
WHERE o.order_status = 'COMPLETED'
GROUP BY c.customer_id, lower(c.email);

Run this through SQLFlow with the Trino dialect selected and the diagram shows, per output column:

Target column (iceberg.analytics.customer_value)	Source column	Relationship
customer_id	postgresql.crm.customers.customer_id	Direct, passthrough
email	postgresql.crm.customers.email	Direct, through lower()
lifetime_value	hive.sales.orders.order_total	Direct, through sum()
order_count	hive.sales.orders rows	Direct, through count(*)
all columns	hive.sales.orders.order_status	Indirect (WHERE filter)
all columns	o.customer_id / c.customer_id	Indirect (JOIN condition, GROUP BY)

Note the last two rows. order_status never lands in the output, but changing how it’s populated changes every number in customer_value. SQLFlow models this as indirect (impact) lineage, a separate, toggleable relationship type alongside direct dataflow. Most lineage tools do not make this distinction, which is exactly the information you need before touching a filter column in a shared Hive table.

Trino and Presto are different dialects — SQLFlow parses both

Trino forked from Presto (as PrestoSQL) and was renamed in 2020; since then the two dialects have diverged. SQLFlow ships separate dialect-specific parsers for Trino and for Presto, among its 39 supported dialects — not one generic ANSI grammar with a compatibility flag. If your estate runs PrestoDB alongside a newer Trino cluster, you select the matching dialect per source and both parse correctly.

The parsers come from the General SQL Parser (GSP), a commercial SQL compiler front-end developed since the mid-2000s and validated against roughly 13,600 per-dialect test fixtures. GSP builds a full semantic model of each statement — resolving column references through CTEs, subqueries, views, and SELECT * expansion — and its data-flow analyzer extracts the source-to-target relationships. Star expansion matters more in Trino than almost anywhere else: SELECT * over a federated join pulls columns from multiple systems, and expanding it correctly requires the schema metadata of each catalog, which SQLFlow can ingest alongside the SQL.

How to generate Trino lineage with SQLFlow

1. Collect the SQL. Paste individual queries, upload files of ETL scripts and view definitions, or pull metadata over JDBC. For whole-estate coverage, the Grabit/SQLFlow-ingester utility extracts metadata in batch.
2. Pick the dialect. Trino or Presto, per source. If the same pipeline also contains Hive DDL or Spark SQL jobs, analyze each in its own dialect; SQLFlow supports all of them, and enterprise deployments store the results in a persistent lineage repository.
3. Explore and export. Trace any column upstream or downstream in the interactive diagram, toggle indirect lineage on or off, and export as JSON, CSV, or PNG — or query the graph through the REST API. Since v8.2.3 you can also ask questions in plain English (“which Iceberg tables depend on postgresql.crm.customers.email?”); every table and column in the AI’s answer is validated against the analyzed graph before display.

At enterprise scale, SQLFlow batch-scans estates of 100+ databases and over a million columns, runs incremental scans, keeps a persistent lineage repository, and exports to DataHub, Microsoft Purview, and OpenMetadata — so Trino lineage lands in the catalog your team already uses.

Static SQL analysis vs. runtime event lineage

The other common way to get Trino lineage is runtime capture: hook the engine’s query events and emit lineage for each executed statement (the OpenLineage ecosystem works this way). Runtime capture is genuinely good at recording what actually ran, with real session context. Its gap is coverage and depth: it only sees queries that executed during the capture window, and it ties you to instrumenting every cluster.

Static analysis, SQLFlow’s approach, parses the SQL code itself. That covers scheduled jobs that haven’t run yet, view definitions, and repository code under review — and it needs no agent on the cluster and never reads table row data. In regulated environments, the On-Premise edition (Docker/Kubernetes) keeps even the SQL text inside your network. Many teams use both: runtime events for operational monitoring, static analysis for complete, pre-deployment impact analysis.

Lineage across the rest of the stack

Trino is rarely the whole story. The Hive tables it queries were usually loaded by Hive or Spark jobs, and results often feed downstream marts. SQLFlow analyzes those layers with the same engine — see the dedicated guides to Hive data lineage and ClickHouse data lineage, or the full SQL data lineage tool overview covering all 39 dialects. With every layer analyzed into the persistent lineage repository, you can trace a column from the Spark job that wrote the Hive table, through the federated Trino query, into the Iceberg target.

Frequently asked questions

Does SQLFlow support both Trino and Presto?

Yes. Trino and Presto are two of SQLFlow’s 39 dialect-specific parsers. Select the dialect that matches your engine; if you run both, analyze each source with its own dialect.

Can SQLFlow trace lineage across Trino catalogs?

Yes. SQLFlow resolves every column to its fully-qualified catalog.schema.table.column identity, so a query joining hive, postgresql, and iceberg catalogs produces lineage that keeps each system’s columns distinct — including for INSERT statements that move data between catalogs.

Does SQLFlow need access to my Trino cluster or data?

No. SQLFlow performs static analysis of SQL code, optionally using schema metadata to resolve names and expand SELECT *. It never reads table rows and needs no agent on the cluster. The On-Premise edition keeps SQL text inside your network entirely.

What does SQLFlow show for columns in WHERE and JOIN clauses?

They appear as indirect (impact) lineage: a separate relationship type for columns that shape the result without landing in the output. You can toggle indirect lineage on and off in the diagram — a distinction most lineage tools do not make at all.

Can I export Trino lineage to my data catalog?

Yes. Enterprise deployments include export adapters for DataHub, Microsoft Purview, and OpenMetadata, plus JSON and CSV export and a REST API for custom integrations.

How much does SQLFlow cost?

SQLFlow Cloud starts free; premium is $49.99/month. SQLFlow On-Premise is $500/month or $4,800 one-time per selected database type, installable on two servers. See pricing for details.