SQLLineage
SQL Lineage Analysis Tool powered by Python
Never get the hang of a SQL parser? SQLLineage comes to the rescue. Given a SQL command, SQLLineage will tell you its source and target tables, without worrying about Tokens, Keyword, Identifier and all the jagons used by SQL parsers.
Behind the scene, SQLLineage pluggable leverages parser library (sqlfluff
and sqlparse) to parse the SQL command, analyze the AST, stores the lineage
information in a graph (using graph library networkx), and brings you all the
human-readable result with ease.
Demo & Documentation
Talk is cheap, show me a demo.
Documentation is online hosted by readthedocs, and you can check the release note there.
Quick Start
Install sqllineage via PyPI:
$ pip install sqllineage
Using sqllineage command to parse a quoted-query-string:
$ sqllineage -e "insert into db1.table1 select * from db2.table2"
Statements(#): 1
Source Tables:
db2.table2
Target Tables:
db1.table1
Or you can parse a SQL file with -f option:
$ sqllineage -f foo.sql
Statements(#): 1
Source Tables:
db1.table_foo
db1.table_bar
Target Tables:
db2.table_baz
Advanced Usage
Multiple SQL Statements
Lineage is combined from multiple SQL statements, with intermediate tables identified:
$ sqllineage -e "insert into db1.table1 select * from db2.table2; insert into db3.table3 select * from db1.table1;"
Statements(#): 2
Source Tables:
db2.table2
Target Tables:
db3.table3
Intermediate Tables:
db1.table1
Verbose Lineage Result
And if you want to see lineage for each SQL statement, just toggle verbose option
$ sqllineage -v -e "insert into db1.table1 select * from db2.table2; insert into db3.table3 select * from db1.table1;"
Statement #1: insert into db1.table1 select * from db2.table2;
table read: [Table: db2.table2]
table write: [Table: db1.table1]
table cte: []
table drop: []
table rename: []
Statement #2: insert into db3.table3 select * from db1.table1;
table read: [Table: db1.table1]
table write: [Table: db3.table3]
table cte: []
table drop: []
table rename: []
==========
Summary:
Statements(#): 2
Source Tables:
db2.table2
Target Tables:
db3.table3
Intermediate Tables:
db1.table1
Dialect-Awareness Lineage
By default, sqllineage use ansi dialect to parse and validate your SQL. However, some SQL syntax you take for granted
in daily life might not be in ANSI standard. In addition, different SQL dialects have different set of SQL keywords,
further weakening sqllineage's capabilities when keyword used as table name or column name. To get the most out of
sqllineage, we strongly encourage you to pass the dialect to assist the lineage analyzing.
Take below example, INSERT OVERWRITE statement is only supported by big data solutions like Hive/SparkSQL, and MAP
is a reserved keyword in Hive thus can not be used as table name while it is not for SparkSQL. Both ansi and hive dialect
tell you this causes syntax error and sparksql gives the correct result:
$ sqllineage -e "INSERT OVERWRITE TABLE map SELECT * FROM foo"
...
sqllineage.exceptions.InvalidSyntaxException: This SQL statement is unparsable, please check potential syntax error for SQL
$ sqllineage -e "INSERT OVERWRITE TABLE map SELECT * FROM foo" --dialect=hive
...
sqllineage.exceptions.InvalidSyntaxException: This SQL statement is unparsable, please check potential syntax error for SQL
$ sqllineage -e "INSERT OVERWRITE TABLE map SELECT * FROM foo" --dialect=sparksql
Statements(#): 1
Source Tables:
<default>.foo
Target Tables:
<default>.map
Use sqllineage --dialects to see all available dialects.
Column-Level Lineage
We also support column level lineage in command line interface, set level option to column, all column lineage path will be printed.
INSERT INTO foo
SELECT a.col1,
b.col1 AS col2,
c.col3_sum AS col3,
col4,
d.*
FROM bar a
JOIN baz b
ON a.id = b.bar_id
LEFT JOIN (SELECT bar_id, sum(col3) AS col3_sum
FROM qux
GROUP BY bar_id) c
ON a.id = c.bar_id
CROSS JOIN quux d;
INSERT INTO corge
SELECT a.col1,
a.col2 + b.col2 AS col2
FROM foo a
LEFT JOIN grault b
ON a.col1 = b.col1;
Suppose this sql is stored in a file called test.sql
$ sqllineage -f test.sql -l column
<default>.corge.col1 <- <default>.foo.col1 <- <default>.bar.col1
<default>.corge.col2 <- <default>.foo.col2 <- <default>.baz.col1
<default>.corge.col2 <- <default>.grault.col2
<default>.foo.* <- <default>.quux.*
<default>.foo.col3 <- c.col3_sum <- <default>.qux.col3
<default>.foo.col4 <- col4
MetaData-Awareness Lineage
By observing the column lineage generated from previous step, you'll possibly notice that:
<default>.foo.* <- <default>.quux.*: the wildcard is not expanded.<default>.foo.col4 <- col4: col4 is not assigned with source table.
It's not perfect because we don't know the columns encoded in * of table quux. Likewise, given the context,
col4 could be coming from bar, baz or quux. Without metadata, this is the best sqllineage can do.
User can optionally provide the metadata information to sqllineage to improve the lineage result.
Suppose all the tables are created in sqlite database with a file called db.db. In particular,
tables baz and quux are created with the following schema:
sqlite3 db.db 'CREATE TABLE IF NOT EXISTS baz (bar_id int, col1 int, col4 int)';
sqlite3 db.db 'CREATE TABLE IF NOT EXISTS quux (quux_id int, col5 int, col6 int)';
Now given the same SQL, column lineage is fully resolved.
$ SQLLINEAGE_DEFAULT_SCHEMA=main sqllineage -f test.sql -l column --sqlalchemy_url=sqlite:///db.db
main.corge.col1 <- main.foo.col1 <- main.bar.col1
main.corge.col2 <- main.foo.col2 <- main.baz.col1
main.corge.col2 <- main.grault.col2
main.foo.col3 <- c.col3_sum <- main.qux.col3
main.foo.col4 <- main.baz.col4
main.foo.col5 <- main.quux.col5
main.foo.col6 <- main.quux.col6
main.foo.quux_id <- main.quux.quux_id
The default schema name in sqlite is called main, we have to specify here because the tables in SQL file are unqualified.
SQLLineage leverages sqlalchemy to retrieve metadata from different SQL databases.
Check for more details on SQLLineage MetaData.
Lineage Visualization
One more cool feature, if you want a graph visualization for the lineage result, toggle graph-visualization option
Still using the above SQL file
sqllineage -g -f foo.sql
A webserver will be started, showing DAG representation of the lineage result in browser:
- Table-Level Lineage
- Column-Level Lineage
Metadata
Release files for sqllineage 1.5.9
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| sqllineage-1.5.9.tar.gz | 362.0 kB | With provenance | Details for sqllineage-1.5.9.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| sqllineage-1.5.9-py3-none-any.whl | Python 3 | none | any | Details for sqllineage-1.5.9-py3-none-any.whl |
Total release size: 844.4 kB
Release files / sqllineage-1.5.9.tar.gz
| Download URL | sqllineage-1.5.9.tar.gz |
|---|---|
| Size | 362.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
f4b9eb0d7e2de52d3d35b4452f39f00bde1cf45d5b3bd4086e4bfe38432aa5f1
|
|
BLAKE2b-256 checksum How to use checksums |
d5a8e0c3e10766eca0cb664beb11dbbb301af446d1131154ca0137f8b8218f24
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 5, 2026.
Transparency logRelease files / sqllineage-1.5.9-py3-none-any.whl
| Download URL | sqllineage-1.5.9-py3-none-any.whl |
|---|---|
| Size | 482.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
b7dfdd7547517b487fdd41291f56203a46ad7199c7db0a5062e9ebd9fbeac406
|
|
BLAKE2b-256 checksum How to use checksums |
8feadca2e9aeea254365695c52457e723d0853926db90252bee3dc306ebccb30
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 5, 2026.
Transparency logSecurity for sqllineage 1.5.9
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for sqllineage-1.5.9.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 5, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.