Show HN: Natural-SQL-7B, a strong text-to-SQL model

Original Article ↗ Hacker News Discussion ↗

A new 7B-parameter text-to-SQL model, Natural-SQL-7B, aims to let non-technical users query databases in plain language while running locally, raising hopes for cheaper, more private analytics than GPT‑4-based solutions. Commenters question its custom “source available” license, its current PostgreSQL focus, and whether a ~75% accuracy rate is sufficient for production use, especially where business logic and KPIs are subtle or domain-specific. Many see value in using such models as drafting tools or in combination with semantic layers, RAG, and strong data governance, rather than as standalone replacements for skilled analysts.

Model capabilities and scope

  • 7B text-to-SQL model, fine-tuned on ~20k synthetic PostgreSQL text→SQL pairs across SQL categories and question types.
  • Evaluated at ~76.5% on SQL-Eval, slightly below GPT‑4 and sqlcoder‑15B.
  • Currently Postgres-focused; broader dialect support (MySQL, DuckDB, MSSQL, BigQuery, Trino) is desired and partly planned.
  • Handles multi-join, aggregation, and subquery questions that are “hard” for non-technical users, but not guaranteed on very complex schemas or business-heavy queries.

Licensing and “open source” debate

  • License includes use-based restrictions (e.g., no military), inherited from the base model.
  • Multiple commenters argue this is not “open source” but “source/weights available.”
  • Concern that nonstandard licenses force legal review vs. familiar MIT/Apache/GPL.
  • Some also note that only model weights are provided, not training code/data.

Use cases, accuracy, and reliability

  • Seen as useful for:
    • Drafting SQL for developers/analysts who can review and fix.
    • Powering local/cli tools where schemas shouldn’t be sent to cloud LLMs.
  • Skeptics question what you can safely automate with ~75% correctness, especially for business-critical analytics and KPIs.
  • Others note humans also make mistakes; value is in speeding up “simple” steps, with humans validating results.
  • Ideas raised: ensembles/consensus, validation via strong DB constraints, using it mainly where correctness is easy to check.

Schema, context length, and semantics

  • 4k context is too small for many real schemas; people discuss using RAG over DDL or wanting 32k+ context.
  • Typical pattern: pass CREATE TABLE DDL (with comments) as prompt; some use RAG on documentation/wiki/dbt to teach semantics.
  • Several argue that the real problem isn’t SQL syntax but understanding data meaning (“what does this ‘price’ or ‘active’ field actually mean?”).
  • Strong support for semantic layers / knowledge graphs / ORMs that encode business logic, with SQL generated deterministically from that layer rather than directly by LLMs.

Cloud vs local, privacy, and trust

  • Some refuse to send schemas or data to OpenAI, citing changing terms, regulatory concerns, or potential government access.
  • Azure OpenAI seen by some as safer but lagging in features/models.
  • This model’s local, weights-available setup is attractive for those with privacy or governance constraints.

Broader reflections on SQL and tooling

  • Debate over learning SQL vs relying on ORMs or LLMs; many emphasize SQL’s lasting value and performance benefits.
  • Others highlight SQL’s ergonomics problems and prefer abstractions.
  • Several note LLMs are already handy for explaining complex SQL, debugging errors, and generating tricky window/percentile queries.