Teradata Data Lineage: Column Lineage for Migrations and Compliance

Teradata data lineage is the column-level map of how data moves through a Teradata estate: which source columns feed each target table, view, and report, and through which joins, expressions, and QUALIFY filters along the way. Gudu SQLFlow builds that map automatically by parsing your Teradata SQL with a dedicated Teradata dialect parser, one of 39 dialect-specific parsers it ships, and renders it as an interactive, drillable diagram with JSON, CSV, and PNG export plus a REST API.

Why Teradata data lineage needs a Teradata parser

Teradata SQL is not ANSI SQL with a different logo. A typical estate that has been running since the BTEQ era carries decades of dialect-specific constructs: SET and MULTISET table definitions, QUALIFY clauses filtering on window functions, named period columns, and scripts written long before anyone thought a machine would ever need to re-read them. A generic ANSI grammar fails on exactly these statements, and every statement a lineage tool fails to parse is a hole in your lineage graph.

SQLFlow takes the opposite approach. It is built on the General SQL Parser, a commercial SQL compiler front-end developed since the mid-2000s and validated against roughly 13,600 per-dialect test fixtures. Its Teradata parser handles BTEQ-era SQL, SET/MULTISET tables, QUALIFY, and named periods as first-class Teradata syntax, then resolves every column reference through CTEs, subqueries, views, and SELECT * expansion before extracting source-to-target relationships at column granularity.

A worked example: tracing a QUALIFY dedup

The QUALIFY ROW_NUMBER() deduplication insert is one of the most common patterns in Teradata warehouses, and a reliable way to break lineage tools that only speak ANSI:

INSERT INTO dw.customer_dim (customer_id, full_name, risk_rating)
SELECT src.customer_id,
       TRIM(src.first_nm) || ' ' || TRIM(src.last_nm) AS full_name,
       src.risk_rating
FROM   staging.customer_feed src
QUALIFY ROW_NUMBER() OVER (
          PARTITION BY src.customer_id
          ORDER BY src.load_ts DESC) = 1;

Run this through SQLFlow and the diagram shows two distinct kinds of relationship:

• Direct lineage: dw.customer_dim.full_name is derived from staging.customer_feed.first_nm and last_nm through TRIM and concatenation; customer_id and risk_rating pass through unchanged.
• Indirect (impact) lineage: load_ts never lands in the target, but it decides which row survives the dedup. SQLFlow records it — along with customer_id in its PARTITION BY role — as an indirect dependency, toggleable separately in the diagram.

That indirect layer matters. If someone changes the grain of load_ts, the dedup silently starts keeping different rows, and no purely direct lineage graph would warn you. Most competing tools do not model indirect lineage at all; SQLFlow treats it as a distinct relationship type.

Use case 1: regulatory lineage for banks on Teradata

Teradata has a deep installed base in banking, and banks carry the heaviest lineage obligations. BCBS 239 expects institutions to demonstrate the accuracy and integrity of risk data aggregation; in practice, that means showing auditors exactly which source fields flow into each regulatory figure and through which transformations. Column-level lineage is that evidence; table-level lineage is an approximation auditors increasingly push back on.

Hand-maintained lineage spreadsheets fail this test the day after they are written. SQLFlow instead derives lineage from the SQL itself: point it at your Teradata DDL, view definitions, and load scripts, and it produces column-level provenance for every regulated output — refreshable on every change through incremental scans, with a persistent lineage repository behind it.

Two properties make this workable inside a bank’s control environment. First, SQLFlow performs static analysis of SQL code only — it never reads row data, so no customer records are touched. Second, the On-Premise edition runs on Docker or Kubernetes entirely inside your network, including air-gapped environments, so not even the SQL text leaves your infrastructure. Enterprise deployments batch-scan estates of 100+ databases and over a million columns, and export adapters for DataHub, Microsoft Purview, and OpenMetadata feed the lineage into whatever catalog your governance team already runs.

Use case 2: migrating off Teradata with the true dependency map

Most Teradata lineage projects today start with a migration: the estate is moving to Snowflake, BigQuery, or Databricks, and someone has to answer what actually depends on what. Guessing from table names and tribal knowledge is how migrations blow their timelines. The dependency map should come from the SQL:

• Scope honestly. Column-level lineage shows which columns feed downstream reports and which are dead weight — logic nothing consumes that you can decommission instead of migrating.
• Sequence migration waves. The lineage graph exposes the real dependency order between subject areas, so you move upstream feeds before the marts that consume them.
• Catch dialect traps. Constructs like QUALIFY, SET table dedup semantics, and named periods all need deliberate translation. Lineage tells you where each construct sits in the dataflow and what is downstream if the translation is wrong.
• Verify after cutover. Because SQLFlow parses both dialects, you can generate Snowflake lineage from the rewritten SQL and compare it against the Teradata baseline — same targets, same source columns, or you have a translation bug.

The same before-and-after workflow applies to other legacy MPP retirements — see the Netezza data lineage page for the decommissioning variant, and the Oracle data lineage page if your estate mixes Teradata with Oracle sources.

How SQLFlow ingests a Teradata estate

You can feed SQLFlow Teradata SQL at whatever scale you are working at:

• Paste a query into the browser for a quick trace of one statement.
• Upload files — DDL exports, view definitions, ETL and load scripts — for a project-sized analysis.
• Connect over JDBC to pull schema metadata and object definitions directly from Teradata.
• Automate with the headless CLI or REST API to keep lineage refreshed as part of your deployment pipeline, and export results as JSON or CSV for anything custom.

For the full picture of what the engine does across all 39 dialects — direct versus indirect lineage, ER diagram inference from DDL, dbt support, the AI lineage query — see the SQL data lineage tool pillar page.

What about open-source and catalog tools?

Open-source parsers like sqllineage and sqlglot are genuinely useful for extracting lineage from individual, mostly-ANSI statements, and catalog-first platforms are good at organizing metadata and ownership across an organization. The gap for Teradata specifically is depth of dialect coverage: decades-old BTEQ-era scripts, QUALIFY-heavy dedup logic, and vendor-specific DDL are precisely where generic grammars stop parsing. If you are evaluating tools for a Teradata estate, the test is simple: run your ugliest production load script through each candidate and count the statements that come back with complete column-level lineage.

Deployment options and pricing

Edition	Best for	Pricing
SQLFlow Cloud	Trying Teradata lineage today; individual analysis work	Free tier; premium $49.99/month
SQLFlow On-Premise	Banks and regulated estates — SQL never leaves your network; air-gapped supported	$500/month or $4,800 one-time per database type, installable on two servers
REST API / CLI / Java library	Embedding lineage into pipelines and platforms	See the pricing page

Additional database types on On-Premise are +$100/month or +$1,000 one-time each, which matters mid-migration when you need Teradata and Snowflake analyzed side by side. Full details on the pricing page.

Frequently asked questions

Does SQLFlow understand Teradata-specific syntax like QUALIFY and SET/MULTISET tables?

Yes. SQLFlow uses a dedicated Teradata dialect parser, not a generic ANSI grammar. BTEQ-era SQL, SET/MULTISET table definitions, QUALIFY clauses, and named periods are all parseable as Teradata SQL, so lineage extraction covers the statements a generic parser rejects.

Can SQLFlow help with a Teradata-to-Snowflake or BigQuery migration?

Yes. Analyze the Teradata estate first to get the true column-level dependency map: what to migrate, what to retire, and in what order. Because Snowflake and BigQuery are also among SQLFlow’s 39 dialects, you can analyze the rewritten SQL after cutover and compare lineage against the Teradata baseline to verify the translation.

Does SQLFlow read data from our Teradata tables?

No. SQLFlow performs static analysis of SQL code and optionally reads schema metadata such as table and column definitions. It never queries row data. With On-Premise, even the SQL text stays inside your network.

Can lineage run fully inside our network for compliance?

Yes. SQLFlow On-Premise deploys on Docker or Kubernetes inside your infrastructure, including air-gapped environments, at $500/month or $4,800 one-time per database type. It scales to estates of 100+ databases and over a million columns, with incremental scans and export adapters for DataHub, Microsoft Purview, and OpenMetadata.

What Teradata inputs does SQLFlow accept?

Pasted SQL, uploaded files (DDL, views, load scripts), and live schema metadata pulled over JDBC. Results are available as interactive diagrams, JSON, CSV, PNG, or through the REST API.

Is column-level lineage enough for BCBS 239?

Column-level lineage is the technical evidence layer: it documents which source fields feed each risk figure and through which transformations, including indirect dependencies from filters and join conditions. Your compliance program defines the full scope; SQLFlow keeps the lineage layer accurate and automatically refreshed instead of hand-maintained.