Netezza Data Lineage: Map Column Dependencies Before Migration

Netezza data lineage is the column-level map of how data moves through your Netezza SQL: which source columns feed each target table, view, and extract, and through which joins, filters, casts, and aggregations. Flujo de SQL de Gudu builds that map automatically by parsing your Netezza code with a dedicated Netezza dialect parser, one of 39 dialect-specific parsers it ships. For most Netezza teams the motivation is not governance paperwork; it is that the appliance is reaching end of life, and you cannot migrate what you cannot see.

Why Netezza data lineage matters now

Netezza appliances powered warehouses at banks, telcos, insurers, and retailers for close to two decades. Those environments accumulated the same things everywhere: thousands of views layered on views, nzsql batch scripts driven by cron, INSERT ... SELECT transforms feeding data marts, and CTAS jobs whose original authors left years ago. Now the hardware is aging out, the platform is end-of-life at many shops, and most are planning (or already executing) a migration to Snowflake, Amazon Redshift, or Google BigQuery.

Every one of those migrations runs into the same wall: nobody has an accurate dependency graph. The documentation, if it exists, describes the warehouse as it was designed, not as it grew. Migrating without lineage means one of two failure modes: you move everything (paying to re-platform tables nothing reads anymore), or you move what you think matters and discover the gaps when a month-end report fails on the new platform.

Column-level lineage extracted directly from the SQL is the fix. It is derived from the code that actually runs, so it cannot drift from reality the way documentation does. And because SQLFlow performs static analysis of the SQL text, it needs no agents on the appliance and never touches row data: it reads code and, optionally, schema metadata.

What lineage looks like on a real Netezza transform

Here is the kind of nzsql-era transform that populates a mart table on thousands of Netezza appliances every night:

INSERT INTO mart.customer_revenue
    (customer_id, region_code, fiscal_month, net_revenue, order_cnt)
SELECT c.customer_id,
       SUBSTR(c.region, 1, 2)               AS region_code,
       TO_CHAR(o.order_date, 'YYYY-MM')     AS fiscal_month,
       SUM(o.amount - o.discount)           AS net_revenue,
       COUNT(*)                             AS order_cnt
FROM   stage.orders o
JOIN   dim.customer c
       ON o.cust_key = c.cust_key
WHERE  o.order_status = 'SHIPPED'
GROUP BY c.customer_id,
         SUBSTR(c.region, 1, 2),
         TO_CHAR(o.order_date, 'YYYY-MM');

Run this through SQLFlow and the diagram shows two distinct kinds of dependency for the target table:

• Direct lineage — data that actually lands in the output: mart.customer_revenue.net_revenue is fed by stage.orders.amount y stage.orders.discount through a subtraction and a SUM; region_code is fed by dim.customer.region through SUBSTR; fiscal_month by stage.orders.order_date through TO_CHAR.
• Indirect (impact) lineage — columns that never land in the output but shape it: o.order_status in the WHERE clause and o.cust_key / c.cust_key in the join condition. Drop or redefine any of them and net_revenue changes, even though no value flows from them.

SQLFlow models direct and indirect lineage as separate, toggleable relationship types — most lineage tools do not make this distinction at all. For migration work the indirect edges are where the surprises hide: a filter column that a generic tool ignores is exactly the column whose changed semantics on the target platform silently shifts your numbers. SQLFlow also resolves column references through CTEs, subqueries, views, and SELECT * expansion, so lineage stays accurate through the view-on-view layering typical of long-lived Netezza estates.

A migration workflow built on lineage

Teams retiring Netezza use lineage in four phases:

1. Map the estate. Feed SQLFlow the DDL, view definitions, and ETL scripts: paste SQL, upload files, or pull metadata over JDBC. Enterprise deployments batch-scan estates of 100+ databases and over a million columns into a persistent lineage repository, with incremental scans as code changes during the migration window.
2. Prune before you move. Any table or view with no downstream consumers in the lineage graph is a candidate to retire rather than migrate. Every object you don’t move is code you don’t have to translate, test, or pay to store.
3. Sequence the cutover. The dependency graph tells you what must move together. Trace downstream from each source table to find the full blast radius of moving it; trace upstream from each critical report to find the minimum set of objects that must be live on the target before that report can cut over.
4. Verify nothing is orphaned. After translation, run the target-side SQL through SQLFlow with the matching dialect parser (Snowflake, Redshift, and BigQuery are all among the 39 supported dialects). Export both graphs as JSON or CSV and diff them: every column edge in the Netezza graph should have a counterpart in the target graph. An edge that exists on Netezza but not on the target is a dependency your translated code dropped, found in review rather than in production.

That before/after verification step is the part manual migration checklists cannot do. Checking that every table exists on the target is easy; checking that every column-level dependency still holds is only practical when both graphs were extracted by the same engine.

How SQLFlow parses Netezza SQL

SQLFlow is built on the General SQL Parser, a commercial SQL compiler front-end (lexer, parser, semantic resolver, and data-flow analyzer) developed since the mid-2000s and validated against roughly 13,600 per-dialect SQL test fixtures. Netezza gets its own grammar in that stack, not a generic ANSI approximation, so Netezza-specific constructs parse as Netezza intends rather than erroring out or being silently skipped.

The output is more than a picture. Alongside the interactive, drillable diagram you get structured lineage data (JSON and CSV export, PNG for documentation), a REST API for automation, and export adapters for DataHub, Microsoft Purview, and OpenMetadata — useful when the migration’s target architecture includes a catalog that should inherit the lineage you extracted. Since version 8.2.3 you can also ask questions in plain English (“what feeds mart.customer_revenue.net_revenue?”) and every table and column the AI cites is validated against the analyzed graph before it is shown.

Deployment matters for this audience: Netezza estates sit disproportionately in banks and insurers. SQLFlow local runs in Docker or Kubernetes inside your network, air-gapped if required, so SQL text never leaves your infrastructure. SQLFlow Cloud has a free tier for trying queries in the browser; premium is $49.99/month, and On-Premise is $500/month or $4,800 one-time per selected database type (see precios).

Netezza vs. its siblings: one engine, consistent lineage

Netezza rarely lives alone. Many shops run it beside Teradata, and the migration target is usually a cloud warehouse. Because SQLFlow uses the same data-flow engine across all 39 dialects, the lineage it extracts is directly comparable across platforms:

Platform	Role in a typical Netezza shop	Lineage page
Netezza	Legacy appliance being retired	This page
Teradata	The other legacy MPP warehouse, often migrating in the same program	Teradata data lineage
Snowflake	Most common migration target; SQLFlow also reads Snowflake query history	Snowflake data lineage
Amazon Redshift	Common AWS-side target; SQLFlow also reads Redshift query logs	Redshift data lineage

Can’t I just use an open-source parser?

For individual queries in mainstream dialects, open-source projects like sqllineage y sqlglot are genuinely good, and if your estate were a few hundred clean SELECT statements they might be enough. The gap shows up on exactly the workload a Netezza retirement produces: a legacy dialect that generic ANSI grammars were never tuned for, view stacks that need semantic resolution and star-expansion against real schema metadata, indirect lineage through filter and join conditions, and the need to visualize and diff lineage across thousands of scripts and two platforms at once. Category-wise, catalog-first platforms and runtime log-based lineage tools face a different limitation here: the appliance you are retiring is the one place you least want to install new collection infrastructure. A fair test is cheap — take your ugliest production transform, run it through both, and compare the column edges. The full picture of what SQLFlow extracts is on the SQL data lineage tool pillar page.

Frequently asked questions

Does SQLFlow have a real Netezza parser or a generic SQL parser?

A real one. Netezza is one of 39 dialect-specific parsers in SQLFlow, built on the General SQL Parser engine and validated against a per-dialect regression corpus of roughly 13,600 SQL fixtures. Netezza syntax is parsed as Netezza, not approximated as ANSI.

Can lineage tell me which Netezza tables are safe to drop before migrating?

Yes, within the SQL you analyze: any table or view with no downstream consumers in the lineage graph is a retirement candidate. Feed SQLFlow all the SQL that touches the warehouse (views, ETL scripts, report queries) so the graph covers every consumer before you act on it.

Does SQLFlow need access to the data on my Netezza appliance?

No. SQLFlow performs static analysis of SQL code and optionally reads schema metadata (table and column definitions). It never reads table rows. With the On-Premise edition, even the SQL text stays inside your network.

How do I verify the migration preserved all dependencies?

Analyze the original Netezza SQL and the translated Snowflake, Redshift, or BigQuery SQL with their respective dialect parsers, export both lineage graphs as JSON or CSV, and diff the column-level edges. Any edge present on Netezza but missing on the target is a dependency the translation dropped.

What does SQLFlow cost for a Netezza migration project?

SQLFlow Cloud starts free, with premium at $49.99/month. SQLFlow On-Premise is $500/month or $4,800 one-time per selected database type, installable on two servers, with additional database types at $100/month or $1,000 one-time each.