Show HN: QueryForge – Natural language to validated database queries

QueryForge AI released QueryForge, a tool that converts natural-language requests into parameterized database queries while keeping access rules and validation in the application rather than the LLM. QueryForge validates each request against a JSON config file the application owns and applies the caller's scope before any SQL exists, binding values as parameters instead of concatenating them into the query string. The tool is available via `go get github.com/awsaman-ai/queryforge`, `pip install queryforge-ai`, and a Maven dependency, and requires a config file plus a model API key with no server or database connection.

QueryForge AI turns natural language into validated and parameterized database queries without giving an LLM direct control over your database. One request, checked against the configuration your application owns, with your access scope applied before any SQL exists. “Show cancelled orders over $200 from the last 30 days, newest first.” SELECT status, created at, amount, customer name FROM orders WHERE subscription id = $1 AND user id = $2 AND status = $3 AND amount $4 AND created at = $5 ORDER BY created at DESC LIMIT 50 "SUB-42", 9, "CANCELLED", 200, <now − 30 days Illustrative output for an orders config. Values are bound as parameters, never concatenated into the query string. A user asks: “Show me customers from India who haven’t ordered in 6 months.” A basic AI integration may turn that request directly into a database query. That can create serious problems. AI is good at understanding language. It should not be responsible for enforcing your application’s rules. The AI understands the request. QueryForge validates it against your rules, applies access controls, and generates the database query. Your AI can understand the user. Your application stays in control. {{ f.body }} Your users shouldn’t need SQL, MongoDB or Elasticsearch, or a page full of filters, to find what they need. Illustrative mock-up. The page keeps one box; QueryForge turns the sentence into the same validated filters the form used to collect. A config file tells QueryForge how your data may be used. Build it in the browser, field by field, or import a MySQL or Elasticsearch schema to start from what you already have, then download the JSON. Your application should not need a different AI integration for every database. QueryForge uses the same validated query plan and generates the format your backend needs. Access rules belong to your application — not the AI. Your application already knows: QueryForge keeps these rules separate from the user’s natural-language request. Secure by design. Controlled by your application. res, err := engine.Translate ctx, "delivered orders over 500 dollars", "sql", qf.Scope{ "subscriptionId": session.SubscriptionID, "userId": session.UserID, "enterpriseId": session.EnterpriseIDs, } WHERE enterprise id IN $1, $2 AND subscription id = $3 AND user id = $4 AND status = $5 AND amount $6 -- args: "E-1", "E-2", "SUB-42", 9, "DELIVERED", 500 A production AI system should not always try to answer. When a request is invalid or unsafe, QueryForge rejects it. {{ r.why }} A safe AI system knows when not to answer. You need a config file build one in your browser config-builder.html and a model API key in your environment. No server, no database connection. go get github.com/awsaman-ai/queryforge pip install queryforge-ai Maven dependency io.github.awsaman-ai:queryforge plus a platform classifier. Exact snippet in the README → https://github.com/awsaman-ai/queryforge install cfg, := qf.LoadConfig "orders.config.json" engine := qf.New cfg res, := engine.Translate ctx, "cancelled orders over 200 dollars", "sql", nil fmt.Println res.Query.SQL // SELECT … WHERE status = $1 AND amount $2 … fmt.Println res.Query.Args // CANCELLED 200 python from queryforge import QueryForge qf = QueryForge.postgres "orders.config.json" pending = qf.query "cancelled orders over $200" print pending.to sql , pending.to args Your users already know what they want. They shouldn’t need to learn SQL to use your application. Let them ask naturally. Give your application a controlled way to understand them. Ask naturally. Control what matters.