Read-only enforcement at the transaction level is what makes this safe to point at a real database: the worst a wrong query does is return the wrong rows. Schema caching and case-sensitivity handling cover the two things that most often break generated SQL, and failures come back as feedback the agent can act on.
A Go server that sits in front of an existing PostgreSQL database, turns natural-language questions into SQL, and returns the rows. It assumes nothing about your schema and requires no changes to it.
- ask takes a plain-language question, generates SQL against your schema and returns the result, streaming automatically when the result set is large
- search does free-text search across the database's text columns
- stream handles very large result sets with pagination
- Every query runs in a read-only transaction, so writes and schema changes are blocked outright
- Query timeouts and input validation, so a bad question cannot pin the database
- Mixed-case table names are handled correctly, which is where naive SQL generation usually falls over
- When the generated SQL is wrong it comes back with the offending statement and a suggestion instead of crashing
- A bundled client returns results as a table, JSON or CSV
An existing PostgreSQL database and its connection string. SQL generation calls a model, so an API key for it; without one the natural-language path is unavailable. Prebuilt binaries, a container image and Kubernetes manifests are provided, and bearer-token authentication can be switched on for the HTTP endpoint.
