Natural language to SQL
Describe what you want in plain English. Get SQL that runs against your schema.
For: everyone. Especially good if SQL isn't your daily language.
The most common AI flow in QueryDeck is "I want X, please write the query". Press Cmd+I, type the request, get SQL back, run it.
A first example
You're connected to a PostgreSQL database with a users table that has columns id, email, created_at, country.
Open the AI panel (Cmd+I). Type:
How many users signed up this week, grouped by country?
The assistant returns:
SELECT country, COUNT(*) AS signups
FROM users
WHERE created_at >= date_trunc('week', NOW())
GROUP BY country
ORDER BY signups DESC;Click Insert into editor, then Cmd+Return to run. Or click Run in the panel to execute and see the result inline in the chat.
What makes the result good
The assistant sees your schema before it answers. That means:
- It uses your actual table and column names, not guesses.
- It picks correct types (e.g.,
date_truncfor PostgreSQL,DATE_FORMATfor MySQL,strftimefor SQLite). - It honors foreign keys when you ask cross-table questions ("orders by user country").
- It knows your dialect — no
LIMIT 10in SQL Server syntax when you're on Postgres.
What you give it matters too. The more specific your prompt, the more useful the result.
| Vague | Specific |
|---|---|
| "Show me users" | "Show the 10 most recent users with email and signup date" |
| "Sum of orders" | "Total order revenue last month, by product category, top 5" |
| "Find duplicates" | "Find rows in users where the same email appears more than once" |
Refining
When the SQL isn't quite right, reply in the chat to iterate. The assistant remembers the conversation within the tab:
Same query, but exclude users where
country IS NULL.
Also include the percent change from last week.
Group by week instead of country.
You can iterate as many times as you need. Each response replaces the SQL in the chat — to keep an earlier version, copy it to the editor before refining further.
Languages other than English
The assistant accepts any language the underlying model supports. For Apple Intelligence and most cloud providers, that includes French, Spanish, German, Japanese, and dozens more.
Combien d'utilisateurs se sont inscrits cette semaine, par pays?
Returns the same SQL as the English version. The output (column aliases, comments) stays in English so the query is portable.
Schema scope
The assistant has the full schema in context, but it focuses on what you're looking at:
| Situation | What's emphasized |
|---|---|
| Editor tab, no specific table open | All tables, equally |
| Viewing a table in Table Mode | That table is highlighted in the schema context |
| Text selected in editor | The selected SQL is the focus; schema is still included |
| Result grid visible | The columns currently shown are emphasized |
This means "show me the most recent ones" works when you're already on a table — the AI knows you mean rows of that table.
When to override the schema
For some workflows, the schema is large enough that the AI loses focus. Two ways to narrow:
- Open the specific table before prompting. The assistant uses that as the primary scope.
- Mention the tables in your prompt: "Using only
ordersandusers, ...". The assistant respects the named tables.
For databases with hundreds of tables, the assistant truncates the schema context to fit the model's context window. Tables that are mentioned in your prompt are always included.
Anti-patterns
Don't paste data into the chat
The assistant doesn't need data to write a query. Schema is enough. Pasting rows:
- Sends real data to whichever AI provider you're using (privacy risk on cloud providers).
- Doesn't help the model write better SQL.
- Fills context with noise.
If you need to discuss a specific row, paste an anonymized representative example or describe it in words.
Don't expect it to know external APIs
"Query the Stripe API and ..." — the assistant only knows your database. If you need to combine SQL with an API call, write the SQL part with the AI and write the API part yourself.
Don't trust the output without reading it
The model gets things wrong. A few patterns to watch for:
- Subtle type mismatches: comparing a string column to an integer literal.
- Missing
WHEREclauses on updates (the assistant should never propose write statements without aWHERE, but verify). - Inefficient queries that work but scan the full table.
Read the SQL before clicking Run. The assistant is a fast first draft, not a senior DBA.
Power moves
Ask for the explanation alongside
Show top 10 customers by total order amount. Include a comment explaining the query.
Returns SQL with inline -- comments. Good for sharing or saving.
Get multiple options
Give me three different ways to compute this — one using a window function, one with a self-join, one with a subquery.
The assistant returns three SQL blocks. Pick the one that fits your style or that the planner prefers (test with EXPLAIN).
Convert from another dialect
Convert this MySQL query to PostgreSQL:
<your query here>
The assistant rewrites function calls, type casts, and quoting to match your active database.
What's next
- Explain, optimize, fix for the three other power features
- Providers to pick a different model
- Privacy to understand what's sent where