.NET comparison

GSP vs Microsoft ScriptDom: beyond T-SQL in .NET

Microsoft ScriptDom is the definitive T-SQL parser for .NET — free, MIT-licensed, first-party, and the engine inside DacFx. If SQL Server is your only dialect, use it. General SQL Parser (GSP) is for .NET teams whose SQL doesn't stop at T-SQL: 38 dialects behind one API — Oracle, Teradata, Snowflake, Db2, and more — plus column-level lineage, impact analysis, offline validation, and formatting.

Send SQL Sample Start Free Trial

Short Answer

Choose ScriptDom when your world is SQL Server: it is the most faithful T-SQL parser available, maintained by Microsoft, at zero cost. Choose GSP when your .NET product must also parse Oracle, Teradata, Snowflake, Db2, PostgreSQL, or any of its 38 dialects — or when you need column-level lineage, impact analysis, and dynamic SQL evaluation as APIs instead of building them on ScriptDom's AST. There is no maintained open-source multi-dialect SQL parser for .NET; this is exactly the gap GSP fills.

Comparison table

CapabilityMicrosoft ScriptDomGSP
What it isMicrosoft’s first-party T-SQL parser and script generator, the engine inside DacFx and SqlPackageA multi-dialect SQL parsing SDK: 38 dialects, validation, formatting, and column-level lineage
DialectsT-SQL only (SQL Server, and T-SQL-compatible Azure SQL surfaces), with versioned parser classes per SQL Server release38 dialects, each with its own dedicated grammar — Oracle, Teradata, Snowflake, IBM Db2, PostgreSQL, MySQL, Informix, Netezza, Sybase, SAP HANA, Vertica, and more, plus T-SQL
License / priceFree — open source under the MIT license, shipped as the Microsoft.SqlServer.TransactSql.ScriptDom NuGet packageCommercial with support SLA and 90-day free trial
Platform.NET onlyJava (JDK 8+) and .NET (.NET Standard 2.0)
T-SQL depthExcellent — first-party AST for the full T-SQL surface, kept current with SQL Server releases by the team that builds the toolingFull T-SQL grammar including procedure bodies, BEGIN/END blocks, TRY/CATCH, and EXECUTE — one grammar among 38
Stored procedures / procedural SQL beyond T-SQLNot applicable — no PL/SQL, DB2 SQL PL, or Teradata supportFully parsed ASTs: PL/SQL packages, types, and triggers; DB2 SQL PL cursors; Teradata procedures and BTEQ, alongside T-SQL
Dynamic SQLParsed as a string argument to EXEC — the SQL inside the string is opaque unless you re-parse it yourselfEvaluated — GSP constant-folds EXEC('...') strings and parameter bindings to recover lineage from dynamic SQL
Column-level lineage / impact analysisNot provided — you get a rich AST and visitor pattern, and build lineage yourselfLineage engine covering queries, stored procedures, dynamic SQL, and multi-statement scripts, with impact analysis and call graphs (the engine behind Gudu SQLFlow)
Syntax validationParse errors with positions for T-SQLOffline validation with detailed error positions across all 38 dialects, no database connection required
SQL formattingSqlScriptGenerator regenerates scripts with configurable options — T-SQL onlyDedicated formatter with 72+ configurable style options, across dialects
Tests / releasesMaintained by Microsoft alongside DacFx and SQL Server releases12,000+ unit tests, releases roughly weekly, 20+ years of development
Support for edge casesGitHub issues on the microsoft/DacFx repositoryCommercial support: send failing SQL, get a fix in a scheduled release

When ScriptDom is the right choice

  • You only parse SQL Server — now and for the foreseeable roadmap.
  • You want a free, MIT-licensed, first-party library with no vendor dependency.
  • A T-SQL AST plus visitors covers your need: linting, code analysis, script generation.
  • You are already inside the DacFx / SqlPackage ecosystem where ScriptDom lives.

When GSP is the better fit

  • Your .NET product must parse more than T-SQL: Oracle, Teradata, Snowflake, Db2, PostgreSQL, MySQL, and more — one API, 38 dialects.
  • Column-level lineage, impact analysis, or call graphs are product requirements, not side projects.
  • Dynamic SQL inside EXEC('...') strings must be analyzed, not treated as an opaque literal.
  • You need offline validation and a cross-dialect formatter with 72+ options.
  • You also ship a Java edition and want the same parser on both stacks.

Evaluation checklist

Test both with the SQL that actually breaks parsers

  1. Inventory your dialects honestly — if anything beyond SQL Server is on the roadmap, weight it now.
  2. Pull 20–100 real statements per dialect, including your longest stored procedures and any dynamic SQL.
  3. For T-SQL, run both parsers; for everything else, ScriptDom is out of scope by design — measure GSP against your non-T-SQL corpus.
  4. Mark the outputs you need: AST detail, validation errors, table/column extraction, or column-level lineage.
  5. Send the failures and edge cases to Gudu — evaluation feedback on real SQL is part of the trial.
Send edge-case SQL .NET SDK Java SDK

Common questions

Should I use ScriptDom instead of GSP?

If your product only ever parses SQL Server, yes — ScriptDom is free, first-party, MIT-licensed, and excellent at T-SQL. There is no reason to pay for a commercial parser for pure T-SQL AST work. GSP earns its license the moment you need a second dialect, or need lineage and impact analysis as ready APIs rather than a project you build on top of the AST.

Is there an open-source multi-dialect SQL parser for .NET?

Not one that covers enterprise dialects with faithful grammars. .NET has strong single-dialect options — ScriptDom for T-SQL above all — but nothing comparable to Python’s sqlglot for breadth. Teams needing Oracle, Teradata, Snowflake, or Db2 parsing in .NET either bridge to non-.NET libraries or use GSP, which ships a native .NET Standard 2.0 edition with all 38 dialects behind one API.

How do I get ScriptDom today?

Install the Microsoft.SqlServer.TransactSql.ScriptDom package from NuGet — Microsoft publishes it standalone, and the source is open under MIT in the microsoft/DacFx ecosystem. Pick the parser class matching your target SQL Server version, and you get a full T-SQL AST with visitors and a script generator.

Can ScriptDom do column-level lineage?

Not out of the box. ScriptDom gives you an accurate T-SQL AST and a visitor pattern — a solid foundation — but lineage requires name resolution across subqueries, CTEs, views, temp tables, and procedure calls, plus handling of dynamic SQL strings that ScriptDom sees as opaque literals. GSP ships that layer as an API: column-level lineage, impact analysis, and call graphs, including through EXEC('...') strings.

Can GSP and ScriptDom be used together?

Yes. A pragmatic split: keep ScriptDom where it is already embedded in your SQL Server tooling and DacFx pipelines, and add GSP where the requirement outgrows T-SQL — cross-dialect parsing, offline validation for Oracle or Teradata code, or lineage and impact analysis across the whole estate.