GSP vs JSqlParser: when free stops being enough on the JVM

JSqlParser is a capable, actively maintained Java SQL parser, and unlike the .NET situation it is a real in-process alternative — so we will not pretend the choice is obvious. It is Apache-2.0 licensed, which means you may ship it inside your own commercial product for free, and we are not going to pretend otherwise. If your SQL is queries in mainstream dialects, use it. General SQL Parser earns its price at two specific points: when your transformation logic lives in stored procedures and dynamic SQL, and when shipping a parser to your own customers means you need a counterparty rather than a warranty disclaimer.

Short answer

Stay on JSqlParser if your SQL is queries, your dialects are mainstream, and you are building internal software. Buy GSP for one of two reasons: because procedural code and dynamic SQL carry the logic you need to analyse, or because you are redistributing a parser commercially and a disclaimed warranty is not an acceptable answer to your customers’ procurement. Do not buy it for a longer feature table.

What a permissive licence does not give you

This is what actually decides commercial evaluations, and it is unrelated to grammar quality. Apache-2.0 lets you ship JSqlParser in your product. It also disclaims warranties, which means the risk stays with you.

 JSqlParser (Apache-2.0)GSP (commercial)
Shipping it inside your commercial productPermitted. Apache-2.0 lets you redistribute — with warranties expressly disclaimed and no indemnity to you or your customer.A Distribution License: a named contract covering redistribution in your product, with Gudu carrying obligations rather than disclaiming them.
When a customer’s SQL breaks the parserYou open a GitHub issue. The project is actively maintained and responsive, but it owes you nothing and no date is promised.You send the failing statement and it is scheduled into a release. That obligation is most of what you are paying for.
Version commitmentYou self-manage. Staying on an older release means giving up fixes for it.You choose the upgrade window; a pinned release keeps receiving fixes under maintenance.
Procurement, security and legal reviewNo counterparty. Nobody to sign a DPA, complete a security questionnaire, or answer your customer’s auditor.A company on the other side of a contract: security review, VPAT and audit questions get answered by a person.

Capability by capability

Where JSqlParser is the better engineering choice, this table says so.

CapabilityJSqlParserGSP
Runs in-process on the JVMYes — and this matters: on the JVM, free in-process parsing genuinely existsYes
LicenseApache-2.0 or LGPL-2.1, free for commercial useCommercial, with a 90-day free trial
Footprint and speedLight, fast, few dependencies — often the better engineering choice when it covers your SQLHeavier; a semantic analysis SDK rather than a parsing library
DialectsOne largely vendor-agnostic grammar with per-dialect accommodations (~12 dialects in practice)42 dialects, each with a dedicated grammar — including Db2, Informix, Netezza, Sybase, SAP HANA, Vertica, Teradata BTEQ, N1QL, SOQL, GaussDB, Dameng, OceanBase and Power Query M
Everyday query parsing (SELECT / INSERT / UPDATE / CTAS)Good. For most JVM applications this is all that is neededEquivalent for this workload. Buying GSP for it alone is not a good reason
Stored procedures / procedural SQLNot the design goal — PL/SQL packages, T-SQL blocks and Db2 SQL PL are outside its scopeFully parsed ASTs: PL/SQL packages, types and triggers; T-SQL blocks, TRY/CATCH, EXECUTE; Db2 SQL PL cursors; Teradata procedures and BTEQ
Dynamic SQLNot evaluatedEvaluated — EXEC(’…’) strings and parameter bindings folded to recover lineage
Name resolution and column-level lineageTable and column references are available from the AST; resolving which table a column belongs to is left to youSemantic resolution with confidence and evidence, and column-level lineage across queries, procedures, dynamic SQL and multi-statement scripts
Offline validationParse success or failureValidation with error positions, no database connection
SQL formattingBasic deparsingDedicated formatter, 72+ style options

Stay on JSqlParser when

  • Your SQL is queries: SELECT, INSERT, UPDATE, DELETE, CTAS.
  • Your dialects are mainstream and its grammar already accepts them.
  • You want a small, fast dependency with no licence cost.
  • You are happy to do your own name resolution on top of the AST.
  • You are building internal tooling, where a warranty disclaimer costs you nothing.

Pay for GSP when

  • You redistribute a parser inside a product you sell, and procurement asks who is accountable.
  • A parse failure in front of a customer is an incident with a deadline.
  • Stored procedures, packages, triggers or dynamic SQL carry the logic you need to see.
  • You need Db2, Informix, Netezza, Sybase, HANA, Vertica, Teradata BTEQ, N1QL, SOQL, GaussDB, Dameng, OceanBase or Power BI’s M language.
  • You need column-level lineage that survives procedures, not just table references from an AST.

Test it on the SQL that actually breaks parsers

  1. Pull 20–100 real statements from your target systems, including your longest stored procedures and any dynamic SQL.
  2. Run them through JSqlParser first and count the hard failures — plus any case where you get an AST but cannot resolve which table a column came from.
  3. If that count is zero, you are done and you do not need us.
  4. If it is not zero, send us those exact statements. We will say which GSP parses today, which are on the roadmap, and which we cannot do either.

Common questions

We use JSqlParser and it works. Why would we pay?

Often you should not, and we would rather say that than waste your evaluation time. JSqlParser is a genuinely good free in-process Java parser, and if your SQL is queries in mainstream dialects it is the right tool. Two things move teams to GSP: the SQL that matters is procedural, or they are redistributing a parser inside a product they sell and want a counterparty instead of a warranty disclaimer. Absent both, stay where you are.

JSqlParser is Apache-2.0. Can we not just ship it in our product for free?

Yes. Apache-2.0 permits redistribution, and we are not going to imply otherwise. What it does not do is move risk off you: warranties are disclaimed, so when a customer hits a parse failure in production the cost and the deadline are yours and nobody is obliged to help. A Distribution License is about who carries that obligation, not about permission. For internal tooling that is worth nothing; for software sold into regulated enterprises it is frequently the entire reason for the purchase.

Is the in-process argument a reason to choose GSP on the JVM?

No, and it would be misleading to suggest it. On the JVM you have real free in-process options — JSqlParser and Apache Calcite both run in your process with no sidecar. The in-process argument only bites on .NET, where the free alternatives are T-SQL-only or syntax-only. On the JVM, judge us on dialect depth, procedural parsing, semantic resolution and the support contract, and on nothing else.

Can we use both?

Yes, and it is usually the cheapest correct answer. Keep JSqlParser on the hot path for ordinary statements and route only what it cannot parse — stored procedures, dynamic SQL, the legacy dialects — to GSP. You pay for the exceptions instead of replacing something that already works.

What if JSqlParser adds the dialects we need?

Then re-run the comparison and switch if it wins. We would rather you re-test annually than buy on a claim that quietly expires. The parsing-depth gap between commercial and free parsers narrows over time; the contractual difference — redistribution with indemnity, a scheduled fix path, an accountable counterparty — does not, because it is structural to open source rather than a feature anyone can add.