{"id":6760,"date":"2026-07-12T02:07:29","date_gmt":"2026-07-12T10:07:29","guid":{"rendered":"https:\/\/www.gudusoft.com\/azure-sql-data-lineage\/"},"modified":"2026-07-12T02:07:29","modified_gmt":"2026-07-12T10:07:29","slug":"azure-sql-data-lineage","status":"publish","type":"page","link":"https:\/\/www.gudusoft.com\/es\/azure-sql-data-lineage\/","title":{"rendered":"Azure SQL Data Lineage: Column Lineage for Azure SQL and Synapse SQL"},"content":{"rendered":"

Azure SQL data lineage<\/strong> is the column-by-column map of how data flows through the T-SQL code running in Azure SQL Database, Azure SQL Managed Instance, and Synapse SQL: which source columns feed each target column, through which views, stored procedures, joins, and functions. The most accurate way to build it is to parse the T-SQL itself. Flujo de SQL de Gudu<\/a> does exactly that with a dedicated Azure SQL dialect parser, and can push the resulting column-level lineage into Microsoft Purview so it appears alongside the rest of your Azure estate.<\/p>\n\n\n\n

\n\n

Try it in 30 seconds:<\/strong> paste any Azure SQL query or stored procedure into the free SQLFlow lineage visualizer<\/a>, select the Azure SQL dialect, and get an interactive column-level lineage diagram. The Cloud edition has a free tier.<\/p>\n\n<\/div><\/div>\n\n\n\n

Why Azure SQL data lineage is a parsing problem<\/h2>\n\n\n\n

On Azure, the transformation logic that actually shapes your data rarely lives in a pipeline definition. It lives in T-SQL: views layered on views, stored procedures called from Azure Data Factory activities, MERGE<\/code> statements, temp tables, and dynamic SQL assembled at runtime. A lineage picture built only from pipeline metadata sees the boxes but not what happens inside them.<\/p>\n\n\n\n

To know that report.monthly_revenue<\/code> is computed as SUM(orders.amount)<\/code> filtered by orders.status<\/code>, something has to read the SQL the way the database engine does: resolve every column reference through CTEs, subqueries, views, and SELECT *<\/code> expansion, then track dataflow from source columns to target columns. That is static SQL analysis, and it is what SQLFlow is built for. It reads SQL code and schema metadata only; it never touches the rows in your tables.<\/p>\n\n\n\n

Where Microsoft Purview stops, and how parsing fills the gap<\/h2>\n\n\n\n

Microsoft Purview is genuinely good at what a catalog-first platform should do: scanning and classifying assets across an Azure estate, mapping sensitive data, and showing lineage for the data movement tools it integrates with, such as Azure Data Factory and Synapse pipelines. If you run Azure at any scale, Purview is a reasonable place for lineage to be displayed<\/em>.<\/p>\n\n\n\n

The gap is in how the lineage gets computed<\/em>. Purview’s automated SQL lineage has gaps on complex T-SQL: stored procedures with control flow, temp-table staging, and dynamic SQL built with sp_executesql<\/code> are precisely the places where automated coverage runs out and lineage edges go missing. Those are also the places where the highest-risk transformations live.<\/p>\n\n\n\n

The division of labor that works: SQLFlow parses the T-SQL and computes column-level lineage, including through procedures and dynamic SQL, then exports it through its Microsoft Purview adapter. SQLFlow does the computation; Purview does the estate-wide display. You keep one catalog, and the SQL-heavy corners of it stop being blank.<\/p>\n\n\n\n

What SQLFlow extracts from Azure SQL code<\/h2>\n\n\n\n

SQLFlow ships 39 dialect-specific parsers rather than one generic ANSI grammar, and Azure SQL is one of them, in the T-SQL family alongside SQL Server. Synapse dedicated SQL pools speak T-SQL too, so the same analysis applies to Synapse SQL scripts. For Azure SQL code, SQLFlow produces:<\/p>\n\n\n\n