Databases / Snowflake
Natural language to SQL for Snowflake
NLQueries is an open source natural language to SQL engine for Snowflake. Ask a question in plain English, get SQL that is validated against your real Snowflake 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 Snowflake 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[snowflake]" $ nlqueries connect snowflake --account myorg.us-east-1 --database ANALYTICS --schema PUBLIC --warehouse COMPUTE_WH --user alice --alias snow-prod $ nlqueries process-history snow-prod --annotate && nlqueries export-kb snow-prod $ nlqueries query snow-prod "how many orders were placed last month by first-time customers?"
How NL2SQL works on Snowflake
Most text-to-SQL tools hand the LLM a schema dump and hope. NLQueries builds a YAML knowledge base from your Snowflake schema and from real query history, in this case the QUERY_HISTORY view in INFORMATION_SCHEMA, 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.
Snowflake-specific details
Snowflake records execution time for every query, so process-history --days N is honoured and you can build the knowledge base from exactly the window you want.
Snowflake commits implicitly around DDL, so the connector's read-only transaction cannot undo a CREATE or DROP. Use a role with SELECT only; the database hardening guide has the grant.
Point the connector at the warehouse you want to pay for: every generated query runs on the warehouse named in --warehouse.
Full connector notes are in the connectors guide, and the read-only role to create is in database hardening. This connector covers Snowflake Data Cloud on AWS, Azure or GCP.
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 Snowflake 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.
Can I limit how much Snowflake compute NLQueries uses?
Yes. The connector runs on the warehouse you name at connect time, so a small dedicated warehouse with auto-suspend bounds the spend, and the statement timeout bounds any single query.
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 · BigQuery · Redshift · SQL Server · DuckDB · SQLite