Let non-technical users ask database questions in plain English and get safely executed SQL results.
Study a worked example of layered guardrails for LLM-generated SQL, from intent checks to a read-only database role.
Run the demo locally against the included customers, products, and orders schema to see the safety pipeline in action.
Use the second-pass LLM validation step as a model for checking whether generated SQL actually answers the original question.
| abhirajthakur/text2sql | 0xkinno/astraea | 0xkinno/halcyon | |
|---|---|---|---|
| Stars | 0 | 0 | 0 |
| Language | TypeScript | TypeScript | TypeScript |
| Setup difficulty | hard | hard | hard |
| Complexity | 4/5 | 4/5 | 4/5 |
| Audience | developer | developer | developer |
Figures from each repo's GitHub metadata at analysis time.
Requires a Postgres database, separate admin and read-only credentials, and both a Groq and a Gemini API key.
Text2SQL lets you ask a question about a PostgreSQL database in plain English and get back an answer, while trying hard to make sure the automatically generated SQL cannot damage the database or return a misleading result. Turning a natural language question into a database query with an AI model is easy to demonstrate but risky in practice, because even a model that works most of the time can still occasionally produce a destructive command or a confidently wrong answer. This project's approach is to add several independent safety checks rather than simply trusting the model. A question passes through several stages before it becomes a final response. First, a simple keyword check looks for destructive intent in the plain English question itself, before any AI call happens. Next, an AI model, primarily one from Groq with a Google Gemini model as a backup, generates the SQL along with an explanation and a confidence score, and this generated SQL is checked for correct syntax with one retry allowed. The SQL is then analyzed structurally to confirm it is a single read-only SELECT statement, is not accessing tables or columns outside an approved list, does not call known dangerous database functions, and has a limit on how many rows it can return. Even after all of that, the query only ever runs against a database account that has read-only permission and a time limit, so a write operation would be blocked at the database level even if every earlier check somehow failed. Finally, a second, independent AI call reviews the question, the SQL, and a sample of the results to judge whether the answer actually addresses what was asked. The project is built as a monorepo with a Cloudflare Workers backend using the Hono framework, a Next.js frontend, and a serverless Postgres database accessed through the Drizzle database toolkit. Running it locally requires installing dependencies with pnpm, setting up a database, and providing API keys for the Groq and Gemini AI services. The README notes some current limitations: it only works with one fixed demo database schema of customers, products, and orders, it is built for a single set of database credentials rather than multiple users, and the final AI-based result check is not a mathematical proof that the SQL is correct, just an added layer of scrutiny. The README does not state a license.
A natural-language-to-SQL tool for PostgreSQL that layers multiple safety checks to stop destructive or wrong queries before they run.
Mainly TypeScript. The stack also includes TypeScript, Next.js, Hono.
Setup difficulty is rated hard, with roughly 1h+ to a first successful run.
Mainly developer.
This repo across BitVibe Labs
Verify against the repo before relying on details.