SQLFlow On-Premise is an on premise data lineage tool: the full Gudu SQLFlow engine, deployed with Docker or Kubernetes inside your own network. It parses your SQL (queries, views, stored procedures, dbt projects, whole database estates) and produces interactive, column-level lineage diagrams while every line of SQL stays behind your firewall. It runs fully air-gapped, and because it works by static analysis of SQL code, it never touches the rows in your tables.
Want to evaluate the engine first? The identical analysis runs in SQLFlow Cloud, free in your browser: paste a non-sensitive query and inspect the column-level output before you talk to procurement.
Why regulated teams need an on premise data lineage tool
SQL text is sensitive even when no data is attached to it. Your DDL exposes the full schema; your views and procedures encode business logic such as risk models, pricing rules, and fraud filters; and ad-hoc SQL frequently embeds literal values: account numbers in a WHERE clause, patient identifiers in a debugging query. Sending that corpus to a SaaS vendor is exactly the kind of third-party data transfer that security reviews at banks, healthcare providers, and government agencies exist to stop.
At the same time, those are the organizations under the most pressure to produce lineage: BCBS 239 expects banks to trace risk figures to their sources, GDPR data mapping asks which fields flow where, and SOX auditors want provenance for financial reporting. The way out of the contradiction is to run the lineage engine where the SQL already lives. That is what SQLFlow On-Premise is for: the same analysis described on our SQL data lineage tool overview, self-hosted.
How deployment works: Docker, Kubernetes, air-gapped
SQLFlow On-Premise ships as containers. Deploy with Docker on a single host, or on your Kubernetes cluster if that is how your platform team runs software. The license covers installation on two servers, so a production instance plus a staging or DR instance costs nothing extra. Step-by-step installation guides are maintained at docs.gudusoft.com.
The deployment works in a fully air-gapped network: the engine has no cloud dependency and does not need an outbound internet connection to analyze SQL. If your environment is a classified network or a payment zone with no outbound routes, SQLFlow still runs. Users reach it through the web interface inside the network, and the same instance exposes a REST API for automation.
The privacy posture: static analysis only
SQLFlow’s privacy model is simple to explain to a security reviewer because it has two hard properties. First, it is a static analyzer: it computes lineage by parsing SQL code, not by observing queries at runtime or sampling tables, so it never reads row data; there is no code path that does. Second, with the On-Premise edition the SQL text itself never leaves your network. What SQLFlow optionally reads over JDBC is schema metadata (table, column, and view definitions), which it needs to resolve SELECT * and view references accurately.
Compare this with runtime log-based lineage approaches, which are genuinely good at capturing what actually executed in production, but require ongoing access to query logs and can only see queries that ran. Static analysis covers the code that exists, including procedures that only fire at quarter-end, and needs nothing but the SQL itself.
What the engine does
On-Premise runs the complete SQLFlow engine, the same one behind SQLFlow Cloud. It is built on the General SQL Parser, a commercial SQL compiler front-end developed since the mid-2000s and validated against roughly 13,600 per-dialect test fixtures.
- Column-level lineage: for every output column, the exact source columns that feed it and the functions, casts, subqueries, joins, and set operators along the way — resolved through CTEs, views, and star expansion.
- Direct vs indirect lineage: columns used in
WHERE,JOIN, andGROUP BYclauses shape results without appearing in them. SQLFlow models this influence as a separate, toggleable relationship type, a distinction most competing tools do not make. - 39 dialect-specific parsers: Oracle, SQL Server, Teradata, DB2, Snowflake, BigQuery, Redshift, Databricks, PostgreSQL, Hive, and 29 more — dedicated grammars per dialect, not one generic ANSI parser.
- Stored procedures and dynamic SQL: dedicated procedural parsers for Oracle PL/SQL and SQL Server T-SQL trace lineage through parameters and temp tables, resolve dynamic SQL, and render an interactive call graph of procedure-to-procedure invocations.
- ER diagrams from DDL: primary/foreign-key relationships inferred from your SQL, drawn as an entity-relationship diagram.
- AI lineage query (since v8.2.3): ask questions in plain English; every table and column the AI cites is validated against the analyzed graph before it is shown.
The stored-procedure depth matters most in exactly the environments that buy on-premise. Legacy banking and healthcare estates run on PL/SQL and T-SQL packages full of patterns like this:
CREATE PROCEDURE dbo.load_regional_summary AS
BEGIN
DECLARE @sql nvarchar(max) =
N'INSERT INTO rpt.daily_summary (region, total_amount)
SELECT region, SUM(amount)
FROM stg.sales_daily
GROUP BY region';
EXEC sp_executesql @sql;
ENDThe lineage here lives inside a string that only executes at runtime. SQLFlow resolves the dynamic SQL and connects rpt.daily_summary.total_amount back to stg.sales_daily.amount; tools that skip dynamic SQL report nothing at all, which in an audit is worse than an error.
Built for estates, not single queries
Enterprise deployments batch-scan estates of 100+ databases and over a million columns into a persistent lineage repository. Incremental scans then process only what changed, so the nightly refresh of a large estate does not mean re-parsing everything. Inputs include live database metadata over JDBC, uploaded SQL files, dbt manifests, Snowflake query history, Redshift query logs, and the Grabit metadata extractor; outputs include JSON, CSV, and PNG export plus the REST API.
If you already run a data catalog, SQLFlow does not compete with it: it feeds it. Catalog-first platforms such as DataHub, Microsoft Purview, and OpenMetadata are good systems of record for metadata, ownership, and discovery, but they depend on something upstream to compute accurate SQL lineage. SQLFlow On-Premise includes export adapters for all three, so it can serve as the lineage engine behind the catalog your teams already use. For a broader look at how the categories fit together, see our comparison of the best data lineage tools.
Pricing
SQLFlow On-Premise is priced per database type (the SQL dialects you select for analysis), not per user or per row scanned. Every license includes installation on two servers and supports 50 users by default.
| License | Subscription | One-time | Includes |
|---|---|---|---|
| Base license (one database type) | $500/month | $4,800 | Two servers, 50 users, full engine, REST API, catalog export adapters |
| Each additional database type | +$100/month | +$1,000 | Added to the same installation |
So an estate spanning Oracle, SQL Server, and Snowflake is $700/month or $6,800 one-time, a number you can put in a budget request without a sales call. Full details are on the pricing page.
On-Premise vs SQLFlow Cloud
| SQLFlow Cloud | SQLFlow On-Premise | |
|---|---|---|
| Where it runs | SaaS at sqlflow.gudusoft.com | Docker/Kubernetes in your network, air-gap capable |
| Where your SQL goes | Analyzed on Gudu-hosted servers | Never leaves your infrastructure |
| Price | Free tier; premium $49.99/month | $500/month or $4,800 one-time per database type |
| Users | Per-account | 50 users by default |
| Best for | Individuals and teams who want lineage today | Banks, healthcare, government, and any estate under data-residency rules |
Both editions run the same parser and produce the same lineage. A common path is to prototype on SQLFlow Cloud with sanitized SQL, confirm the output quality on your hardest procedures, then move to On-Premise for the real estate.
Keep the lineage engine behind your firewall
Tell us your database mix and estate size and we’ll scope a deployment — or prove the engine on sanitized SQL in the free cloud tier first.
Frequently asked questions
Can SQLFlow On-Premise run fully air-gapped?
Yes. It deploys as Docker or Kubernetes containers and operates with no outbound internet connection and no cloud dependency in the analysis path.
Does SQLFlow ever read the data in my tables?
No. SQLFlow is a static analyzer: lineage is computed by parsing SQL code. It optionally reads schema metadata (table, column, and view definitions) over JDBC, but it never reads row data, and with On-Premise the SQL text itself stays inside your network.
How much does SQLFlow On-Premise cost?
$500/month or $4,800 one-time per selected database type, covering installation on two servers and 50 users by default. Each additional database type is +$100/month or +$1,000 one-time on the same installation.
How many users does a license support?
50 users by default per license. For larger teams, contact Gudu Software to size the deployment.
Which databases can SQLFlow On-Premise analyze?
39 dialects, each with its own parser: Oracle, SQL Server, Teradata, DB2, Sybase, Informix, PostgreSQL, MySQL, Snowflake, BigQuery, Redshift, Databricks, Hive, Spark SQL, and more. Licensing is per database type, so you pay only for the dialects in your estate.
Can it feed lineage into our existing data catalog?
Yes. Export adapters for DataHub, Microsoft Purview, and OpenMetadata are included, alongside JSON and CSV export and a REST API for custom integrations.
Bring data lineage inside your network
Tell us your database mix and estate size, and we’ll scope a deployment — or start with the installation guides and stand it up yourself.