Databases / Amazon Redshift
Natural language to SQL for Amazon Redshift
NLQueries is an open source natural language to SQL engine for Amazon Redshift. Ask a question in plain English, get SQL that is validated against your real Redshift 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 Redshift 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[redshift]" $ nlqueries connect redshift --host my-cluster.abc123.us-east-1.redshift.amazonaws.com --port 5439 --database dev --user awsuser --alias redshift-prod $ nlqueries process-history redshift-prod --annotate && nlqueries export-kb redshift-prod $ nlqueries query redshift-prod "how many orders were placed last month by first-time customers?"
How NL2SQL works on Redshift
Most text-to-SQL tools hand the LLM a schema dump and hope. NLQueries builds a YAML knowledge base from your Redshift schema and from real query history, in this case STL_QUERY (needs superuser or pg_read_all_stats), 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.
Redshift-specific details
Redshift has no equivalent of PostgreSQL's pg_description, so schema descriptions are not available; the knowledge base is built from table and column names, row counts from SVV_TABLE_INFO, and your query history. Annotating the knowledge base YAML by hand pays off more here than on other engines.
REDSHIFT_SOCKET_TIMEOUT_SECONDS bounds the whole connection, including how long a query may run without sending data. It defaults to the statement timeout plus 30 seconds and also covers a Serverless workgroup resuming from idle.
Full connector notes are in the connectors guide, and the read-only role to create is in database hardening. This connector covers Redshift provisioned clusters and Redshift Serverless.
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 Amazon Redshift 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 Redshift Serverless?
Yes. The same connector covers provisioned clusters and Serverless workgroups; the socket timeout default leaves room for a workgroup to resume from zero before answering the first connection.
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: Postgres · MySQL · Snowflake · BigQuery · SQL Server · DuckDB · SQLite