Six new NL2SQL repositories show why inspectable controls are not the same as adoption

A small wave of newly created NL2SQL repositories is making the field easier to inspect. It is not yet making the projects proven.

A directory check on October 25 found six recent entrants with concrete implementation details: gbi, Showboard, Text-to-SQL Interface, Text-to-SQL RAG Studio, ZG BI, and Overseas Tax Agent. Together they are useful evidence of what builders now consider table stakes. They are not evidence that those choices work in independent deployments.

Controls arrive before users

The repositories lead with safety and deployment boundaries. gbi describes read-only query controls and ships as an AGPL-3.0 self-hosted system. Showboard advertises read-only SQL over PostgreSQL, SQLite and files under an MIT license. Text-to-SQL Interface documents parser-backed SQL validation and schema checks, while Text-to-SQL RAG Studio combines schema retrieval with self-correction. ZG BI exposes semantic metrics and row-level controls, but GitHub identifies its license only as “Other/NOASSERTION.”

Those details matter because they are inspectable. Licensing, repository activity and implementation boundaries can be checked without accepting a vendor’s product copy. Yet the adoption signal is tiny: the six repositories had between zero and two GitHub stars and no forks when checked. Stars are a weak proxy for use, but zero independent forks, case studies or public reproductions means the directory should describe these systems as early-stage rather than established alternatives.

One evaluation exposes the right caveats

Overseas Tax Agent is the clearest example of both the promise and the gap. Its README reports a 200-case synthetic evaluation across a rules-based baseline and three model configurations. The design assigns tax arithmetic to deterministic Python code and leaves classification and explanation to the model. It also publishes latency, cost, loop failures and a five-run confidence-threshold sweep instead of reporting one aggregate accuracy number.

But the same README says the SQL-query and regulation-search tools are still stubs. The repository has no declared license or tagged release, and the evaluation is author-run on synthetic cases. Its reported 100% classification and blocking results therefore describe a controlled baseline, not a validated production system.

How the directory should read these projects

The right response is neither dismissal nor promotion. Inspectable guardrails deserve credit; missing licenses, stubbed paths and absent independent use deserve equal prominence. For new NL2SQL entrants, a useful directory record should separate four questions:

1. Can the implementation be inspected and legally reused?
2. Are dangerous query paths constrained by code or only by prompting?
3. Is the evaluation runnable, and are its data and limitations visible?
4. Has anyone besides the author adopted or reproduced it?

This sample clears parts of the first three questions. It does not clear the fourth. That distinction is the difference between promising engineering evidence and ecosystem traction.