Databases / PostgreSQL
Natural language to SQL for PostgreSQL
NLQueries is an open source natural language to SQL engine for PostgreSQL. Ask a question in plain English, get SQL that is validated against your real Postgres schema before it runs, and see the answer. It works from the command line, as a Python library, and as an MCP server for Claude Desktop, Cursor and other AI assistants.
Connect Postgres and ask your first question
Install the package, register the connection once, build the knowledge base, and query. Passwords are prompted for interactively and stored in your OS keychain, never in a config file.
$ pip install nlqueries-core $ nlqueries connect postgres --host db.example.com --port 5432 --database prod --user alice --alias prod $ nlqueries process-history prod --annotate && nlqueries export-kb prod $ nlqueries query prod "how many orders were placed last month by first-time customers?"
How NL2SQL works on Postgres
Most text-to-SQL tools hand the LLM a schema dump and hope. NLQueries builds a YAML knowledge base from your Postgres schema and from real query history, in this case the pg_stat_statements extension, so it learns which joins your team actually uses and what your columns mean. That knowledge base is what the model sees when it writes SQL.
Every generated statement is parsed and checked column-by-column against the live schema with sqlglot before execution, then run inside a read-only transaction with a statement timeout. Use nlqueries ask to see the SQL without executing it, or nlqueries query to run it. A semantic cache answers repeated questions without another LLM or database round-trip.
Postgres-specific details
Query-history capture needs pg_stat_statements. Managed PostgreSQL (AWS RDS, Google Cloud SQL, Supabase, Neon, Azure Database for PostgreSQL) pre-loads the library, so CREATE EXTENSION IF NOT EXISTS pg_stat_statements; is the only step. Self-hosted servers need shared_preload_libraries = 'pg_stat_statements' in postgresql.conf and a restart.
Column and table comments from pg_description are pulled straight into the knowledge base, so documenting your schema in Postgres directly improves the SQL that gets generated.
TLS is configured with the SSL_MODE and SSL_CA_CERT environment variables rather than a connect flag.
Full connector notes are in the connectors guide, and the read-only role to create is in database hardening. This connector covers Postgres, AWS RDS for PostgreSQL, Supabase, Neon, Cloud SQL and Azure Database for PostgreSQL.
Use it from Claude, Cursor or any MCP client
Run nlqueries mcp-server and point Claude Desktop, Cursor, or any Model Context Protocol client at it. The assistant can then query PostgreSQL through the same validated pipeline, with OIDC authentication and per-tool authorization available for network transports. See MCP authentication.
Frequently asked questions
How does NLQueries turn a natural language question into SQL?
It retrieves the relevant tables, columns, relationships and past query patterns from a YAML knowledge base built from your schema and query history, asks an LLM for SQL with that context, validates the SQL against your real schema with sqlglot before it runs, and executes it inside a read-only transaction with a statement timeout.
Is the generated SQL safe to run against production?
Generated SQL is validated column-by-column against the live schema, executed read-only with a timeout, and can be previewed with nlqueries ask without touching the database. Pair that with a least-privilege database role and it is designed for production use.
Does NLQueries work with Supabase, Neon, RDS or Cloud SQL?
Yes. They are all PostgreSQL, and all of them ship with pg_stat_statements pre-loaded, so query-history capture works after a single CREATE EXTENSION statement.
Can Claude Desktop or Cursor query this database through NLQueries?
Yes. nlqueries mcp-server exposes the same pipeline as a Model Context Protocol server, so any MCP client can ask questions and get validated SQL results as a native tool call.
Other engines: MySQL · Snowflake · BigQuery · Redshift · SQL Server · DuckDB · SQLite