SQL Lineage and Impact Analyzer

Paste SQL or import a project to follow sources through transformations and inspect downstream impact. Schema definitions improve resolution; dynamic SQL may remain incomplete.

Runs locally in your browser

View category: SQL & Databases (12)

LOCAL ONLY Column Lineage Static Analysis

Your SQL, schema and uploaded files are analyzed inside this browser. KivTools does not upload them for lineage analysis.

INPUT

Input workspace

Preparing local SQL engine…

No files selected Drop SQL, ZIP or dbt files here

Dialect

Choose the actual SQL dialect when known for more accurate parsing.

OUTPUT

Lineage graph

Waiting for analysis

Trace a column from source to output

Load the example or paste SQL, then analyze it with the local SQLGlot engine.

Direct Transformation Context

QUALITY

Analysis coverage

Source	Statement	Status	Confidence

Details

Select a node in the graph

Node details, SQL fragments and text lineage paths appear here.

Downstream impact

Deterministic paths

Select a source column to count affected columns, views and final results.

Source SQL

SQL LINEAGE

Trace SQL dependencies before changing a query

Column lineage follows source columns through expressions, CTEs and views to each output. Impact analysis reverses those paths to show what a source change can affect.

What this analyzer resolves

SELECT, aliases, JOIN, subqueries, CTEs, UNION, aggregates, window functions, QUALIFY, MERGE, CREATE VIEW, CTAS and INSERT SELECT.

When schema information helps

CREATE TABLE definitions improve SELECT * expansion, ambiguous-column resolution and qualification.

Static-analysis limits

Dynamic SQL and stored procedures may be incomplete. Runtime database behavior is never executed.

How to read column lineage from SQL

Paste SQL or upload .sql files, choose a dialect and press Analyze lineage. The parser is SQLGlot 30.17.0 running on Pyodide inside a Web Worker: the engine files are downloaded once — the status chip shows Pyodide, then SQLGlot — and every analysis after that happens in the page. Nothing is sent to a server for parsing and no database is contacted.

The result is a graph plus an inspector. Columns mode follows values from source columns through expressions to each output; Tables mode collapses the graph to table and view dependencies; Joins mode keeps only the ON relationships. Under the graph, the Analysis coverage card reports each statement as resolved, partial, unsupported or a parse error, and the Warnings card names what could not be resolved.

Type or paste the statements, or press Load example. The Schema tab takes CREATE TABLE definitions — they are what allows SELECT * to be expanded and ambiguous columns to be qualified.

Leave the dialect on Detect automatically or pick one from the list of 23. Detection reads vendor markers in the text; when they are too thin to be sure, the page asks you to choose a dialect instead of guessing.

Press Analyze lineage. Coverage and the graph appear together; Cancel stops a running analysis, and the engine is reloaded for the next run.

Inspect: search for a table, view or column, filter the selected node's neighbourhood with Upstream or Downstream, and switch Context on to add the dependencies that are used but not passed through, such as filter and grouping keys. Click a node for its SQL fragment and expression; the Downstream impact card counts the columns, views and final results a change would reach.

Export JSON, CSV, PNG, SVG or GraphML. Every file is produced locally in the browser; the CSV holds one row per edge with source, target, relation, statement, file and expression.

What the analyzer resolves, and what it leaves out

Reading the graph

A direct edge means the target is taken straight from the source, as a plain reference or an alias. A transformation node appears when the value is computed: aggregated, cast, concatenated or wrapped in a function, and the Details panel shows the expression behind it. The node and edge counts of the current view are printed above the canvas, and the zoom, fit, minimap and fullscreen controls work on the rendered graph.

Context adds dependencies that are used without being passed through — filter columns in WHERE, join keys, grouping keys. Turning it on visibly widens the graph, which is why it is separate from the lineage filter buttons.

Dialects and detection

The dialect list runs from ANSI / Generic SQL through PostgreSQL, MySQL, SQL Server / T-SQL, Oracle, SQLite, Teradata, Snowflake, BigQuery, Amazon Redshift, Databricks SQL, Microsoft Fabric, DuckDB, ClickHouse, Materialize, Apache Doris, Dremio, Spark SQL, Hive, Trino, Presto and Amazon Athena. The parser follows the choice: quoted identifier characters, LIMIT / TOP / FETCH FIRST and MERGE syntax are the usual reasons the same text resolves in one dialect and fails in another.

Detection is evidence-based. A MySQL dump header, ENGINE=InnoDB, a backtick or AUTO_INCREMENT, :: casts or COPY … FROM stdin, GO or [dbo]., VARCHAR2 and TABLESPACE, PRAGMA, TIMESTAMP_NTZ and similar markers each vote for a dialect. A plain SELECT with no vendor syntax carries no evidence, so the page asks you to pick rather than guess; the Example button then loads a sample written for the dialect you chose, such as QUALIFY for BigQuery and Snowflake, MERGE for Databricks or NVL for Oracle.

Coverage, warnings and limits

Coverage is reported per statement — resolved, partial, unsupported or parse error — with a confidence of high, medium or low, so a long script shows exactly which parts the engine understood. Warnings point at the specific cause: SELECT * without a matching schema, a column that exists in two joined tables, dynamic SQL, or a statement the lineage engine does not fully support yet.

Everything here is static analysis: dynamic SQL and stored procedures can only be followed as far as their text allows, no statement is executed, and the detail of the result depends on the schema you provide. Uploads accept .sql text files, project import accepts a folder or a ZIP / dbt project up to 25 MB compressed and 50 MB extracted, and the combined input is capped at 50 MB — a notice appears above 5 MB. The engine itself is several megabytes of WebAssembly, so a cold first analysis takes longer than the ones that follow.