Databases / SQLite
Natural language to SQL for SQLite
NLQueries is an open source natural language to SQL engine for SQLite. Ask a question in plain English, get SQL that is validated against your real SQLite 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 SQLite 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 sqlite --database /data/app.db --alias app-local $ nlqueries process-history app-local --annotate && nlqueries export-kb app-local $ nlqueries query app-local "how many orders were placed last month by first-time customers?"
How NL2SQL works on SQLite
Most text-to-SQL tools hand the LLM a schema dump and hope. NLQueries builds a YAML knowledge base from your SQLite schema and from real query history, in this case none; SQLite is file-based and keeps no query history, 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.
SQLite-specific details
SQLite ships with Python, so no extra install is needed. --database is a file path, or :memory: for a transient database.
The knowledge base is built from PRAGMA table_info and PRAGMA foreign_key_list, so declared foreign keys turn directly into join hints.
SQLite has no server-side statement timeout; a runaway query is interrupted best-effort by a watchdog, and DDL runs outside the transaction, so keep the file read-only at the OS level if the data matters.
Full connector notes are in the connectors guide, and the read-only role to create is in database hardening. This connector covers SQLite files, including app databases and exported datasets.
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 SQLite 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.
Is SQLite a good way to try NLQueries?
It is the fastest way. No server, no credentials, no extra packages: point nlqueries connect sqlite at any .db file, run export-kb, and ask a question.
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 · Redshift · SQL Server · DuckDB