{"id":6794,"date":"2026-07-12T04:30:28","date_gmt":"2026-07-12T12:30:28","guid":{"rendered":"https:\/\/www.gudusoft.com\/sql-data-lineage-platform\/"},"modified":"2026-07-12T04:30:28","modified_gmt":"2026-07-12T12:30:28","slug":"sql-data-lineage-platform","status":"publish","type":"page","link":"https:\/\/www.gudusoft.com\/fr\/sql-data-lineage-platform\/","title":{"rendered":"SQL Data Lineage Platform (SDLP)"},"content":{"rendered":"

SDLP (SQL Data Lineage Platform)<\/strong> is Gudu Software’s enterprise lineage system of record. It computes column-level data lineage for an entire SQL estate by parsing the estate’s actual code \u2014 stored procedures, views, functions, triggers, jobs \u2014 and stores every derived lineage edge as an auditable fact<\/strong> in a governed repository, together with a complete ledger of everything it could not<\/em> resolve. The result is lineage you can defend in front of a regulator: facts plus rejects always account for 100% of the estate, nothing is silently dropped, and nothing is fabricated.<\/p>\n\n\n\n

\n\n

Where SDLP sits in the SQLFlow family:<\/strong> it is built on the same General SQL Parser core as Gudu SQLFlow<\/a>, but solves a different problem. SQLFlow shows you the lineage of the SQL you give it; SDLP maintains the attested lineage record of everything your estate contains. The comparison below makes the split precise.<\/p>\n\n<\/div><\/div>\n\n\n\n

SQLFlow or SDLP \u2014 which one do you need?<\/h2>\n\n\n\n

Gudu SQLFlow<\/a> is an interactive lineage analysis and visualization engine<\/em>. You give it SQL \u2014 pasted, uploaded, pulled from a database, a dbt project, or query history, in any of 39 dialects \u2014 and it renders an interactive column-level lineage diagram in seconds. It is the right tool for data engineers and analysts who need to understand, debug, and document data flows, and it ships as SQLFlow Cloud<\/a>, SQLFlow sur site<\/a>, a REST API, and a Java library.<\/p>\n\n\n\n

SDLP is an enterprise lineage platform<\/em> \u2014 a system of record. It does not analyze one script at a time: it exports a whole database estate (metadata plus every module’s SQL source), scans it as a tracked batch, and merges the results into a canonical repository of lineage facts with evidence, quality scores, governance, access control, and a tamper-evident audit trail. It is the right tool for data governance teams at banks, insurers, and other regulated enterprises who must prove<\/em> where data comes from \u2014 continuously, at estate scale, with the gaps accounted for.<\/p>\n\n\n\n

\n\n
<\/th>Gudu SQLFlow<\/th>SDLP<\/th><\/tr><\/thead>\n
What it is<\/strong><\/td>Interactive lineage analysis & visualization engine<\/td>Enterprise lineage system of record with governance<\/td><\/tr>\n
You give it<\/strong><\/td>SQL scripts, a database connection, dbt artifacts, query history<\/td>A whole SQL estate, exported as a metadata + source bundle<\/td><\/tr>\n
You get<\/strong><\/td>An interactive column-level lineage diagram, exportable as JSON\/CSV\/PNG<\/td>A governed repository of auditable lineage facts, a reject ledger, quality-scored scan batches, and regulator-ready exports<\/td><\/tr>\n
Unresolved SQL<\/strong><\/td>Best-effort diagram of what was parsed<\/td>Recorded in a reject ledger with reason code and evidence \u2014 facts + rejects = 100% of the estate<\/td><\/tr>\n
Dialect coverage<\/strong><\/td>39 SQL dialects<\/td>Microsoft SQL Server estates end-to-end today; further estate types on the roadmap, powered by the same parser family<\/td><\/tr>\n
Typical user<\/strong><\/td>Data engineers, analysts, architects<\/td>Data governance teams, scan operators, stewards, auditors<\/td><\/tr>\n
Governance<\/strong><\/td>\u2014<\/td>PII classification, sensitive-flow impact analysis, baselines, role-based access, hash-chained audit trail<\/td><\/tr>\n
Id\u00e9al pour<\/strong><\/td>Understanding and documenting data flows during development<\/td>Regulatory lineage (BCBS 239-style), enterprise catalogs, audit evidence<\/td><\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n

The two products are complementary: teams typically use SQLFlow during development to understand and fix data flows, and SDLP in production to maintain the attested lineage record the organization reports against.<\/p>\n\n\n\n

Honest lineage: reject, don’t guess<\/h2>\n\n\n\n

Most lineage tools fail audits on silent gaps<\/em>: whatever the tool did not understand simply is not there, and nobody can say how much is missing. SDLP’s founding doctrine is different \u2014 reject, don’t guess, and account for 100%<\/strong>. Every statement or reference the scanner cannot honestly resolve becomes a row in the reject ledger with a machine-readable reason code, a severity, and the raw SQL evidence. Ambiguity is never coerced into a plausible-looking edge, and out-of-estate references are classified as external rather than guessed at. “Facts plus rejects equals the whole estate” is a checkable equation, not a slogan.<\/p>\n\n\n\n

The same honesty runs through the data model. Every lineage fact carries a role<\/strong> that states how<\/em> the source column affects the target: value-carrying roles (DIRECT, TRANSFORM, AGGREGATE, DERIVED) mean source data actually lands in the target; influence-only roles (FILTER, JOIN, CONDITION) mean the source column shaped the result without its value ever arriving. That distinction is the difference between “this report contains<\/em> customer PII” and “this report was merely filtr\u00e9 par<\/em> a PII column” \u2014 exactly what a privacy officer or regulator needs, and SDLP never overstates the former when only the latter is true.<\/p>\n\n\n\n

Comment \u00e7a marche<\/h2>\n\n\n\n
  1. Export.<\/strong> A single self-contained exporter connects to the source server with a read-only login and streams the whole estate \u2014 catalog metadata and every module’s SQL text \u2014 into a sharded bundle. It reads metadata only<\/em>, never table data, and runs inside your network zone; the bundle is the only thing that leaves it.<\/li>\n
  2. Scan.<\/strong> The scanner parses and analyzes every module with the General SQL Parser, normalizes the results, and merges them into the canonical repository as a tracked, resumable batch. An interrupted scan resumes from its checkpoint ledger instead of starting over.<\/li>\n
  3. Validate.<\/strong> An independent validator \u2014 a deliberately separate implementation \u2014 recomputes the identity hash of every stored row and runs a rule catalog that condenses into a 0\u2013100 quality score per batch: one number to judge every scan by.<\/li>\n
  4. Consume.<\/strong> A web catalog serves search, interactive lineage graphs, and governance workflows; the Export Center delivers CSV, JSONL, or Parquet to downstream systems, including a Microsoft Purview-ready lineage CSV.<\/li><\/ol>\n\n\n\n

    Every step works from the command line, from the browser, or mixed \u2014 all three routes read and write the same repository under the same identity contract, so choosing an interface never forks the data. Scan operations teams typically run scheduled scans by CLI, analysts and stewards live in the web UI, and downstream feeds run against the export API.<\/p>\n\n\n\n

    Evidence you can hand to an auditor<\/h2>\n\n\n\n

    Every fact in the repository traces to its origin through a tamper-evident chain: fact \u2192 occurrence \u2192 a byte-precise locator into the exported source bundle, re-verified against a SHA-256 content hash on every read. SQL text is not duplicated into the repository; the bundle is the single system of record, so edited or drifted source is detected rather than silently served. In the web catalog, “View SQL evidence” opens the exact statement span, highlighted in the original module source and hash-verified live.<\/p>\n\n\n\n