Generate SQL with Natural Language
The AI Assistant reads the active Connection schema, turns a natural-language request into SQL, and decides whether it can run according to the execution policy stored for that Connection, database, and schema.
How to use
Open AI Chat from a project. The AI SQL Editor can activate automatically when a completed answer contains SQL.
Open the AI Assistant
Click the AI button on the right side of the project or press Ctrl/Cmd+I.
Select a key and database
At the top, verify the provider key, Connection, and database/schema.
Send a natural-language request
Describe the data and conditions you need, then press Enter or select Send. Use Shift+Enter for a new line.
Review the explanation and SQL
The answer is divided into explanation and SQL blocks. You can copy SQL from its block in Chat, while execution takes place in the AI SQL Editor.
Inspect execution results
Review execution status, returned or affected rows, and rerun history in the AI SQL Editor.
Connection context
The AI uses the selected DBMS and database/schema as the default context for writing SQL. It can retrieve metadata and limited real database values when needed, while actual access is determined by the Connection's database account permissions.
- Key: the provider key and model used for the request
- Connection: the database connection used to write and run SQL
- Database/Schema: the default scope used to inspect tables and columns
- When needed, the AI checks tables, views, columns, keys, indexes, relationships, and constraints automatically
Note: After the first message starts a session, its key and database context are locked. Create a new session before selecting another Connection or schema.
Database lookup while answering
The AI can use metadata tools and a read-only SELECT tool to produce a more accurate answer.
- Metadata lookup: inspects tables, views, columns, keys, indexes, relationships, and constraints.
- Internal SELECT: returns at most 10 rows within 30 seconds per call and cannot execute DML or DDL.
- With the tool policy set to Always allow, internal SELECT runs immediately. With Approval required, the request waits for the user to allow it from an approval card in Chat.
- Results are masked before reaching the provider according to the project's sensitive-column masking policy. Original values may be sent depending on the policy and classification result.
Note: Internal SELECT is a limited lookup used to produce an answer. The per-schema SQL execution policy below separately decides whether generated SQL in the final answer can run.
Per-schema execution policies
A project owner can configure SELECT, DML, and DDL independently for each Connection, database, and schema from AI Settings in the header. New coordinates default to automatic SELECT execution and confirmation before DML or DDL execution.
| SQL type | Default | Available values |
|---|---|---|
| SELECT | Auto-run candidate | Run automatically / Confirm before execution |
| DML | Confirm before execution | Run automatically / Confirm before execution |
| DDL | Confirm before execution | Run automatically / Confirm before execution |
Caution: Automatic execution processes eligible statements when the answer completes. Confirm before execution waits until the user selects Run and approves the confirmation dialog. Unclassifiable SQL (UNKNOWN) is not executable, and DML or DDL on a Connection not marked as a Test DB by the server requires confirmation regardless of policy. Connection protection, read-only rules, and DDL permissions can add confirmation or block execution. Changing a policy never retroactively runs existing SQL.
Automatic and manual execution both use a new Auto Commit connection. Statements are evaluated and run independently in sequence, so an allowed later statement can run after an earlier failure and prior changes are not rolled back. Commit and Rollback in the regular SQL Editor do not apply to these runs.
AI SQL Editor
Chat presents the explanation and SQL, while the AI SQL Editor manages execution state and results.
- A Generated SQL Query Block is created for each SQL block returned by the AI.
- Select execution history for automatic and manual runs and inspect each status.
- Review SELECT rows, DML affected rows, errors, and whether any result data was omitted.
- Run the same Query Block again to create a new execution record.
- Query Blocks are read-only. Copy SQL into the regular SQL Editor to edit it.
- Execution history lasts only for the current app runtime and is not restored when a saved Chat is reopened.
Note: A single execution returns up to 10,000 rows. Some data can be omitted by response-size or long-cell limits. When JDBC returns multiple results, only the first result is displayed.
Prompt examples
Include the goal, date range, filters, and desired output columns to get more accurate SQL.
| Goal | Example prompt |
|---|---|
| Aggregation | Show monthly order totals for the last six months and the percentage change from the previous month. |
| Relationship query | Show the ID, name, and last order date for active members who have not ordered in the last 30 days. |
| Data change | Write an UPDATE that deactivates temporary coupons past their expiration date. Explain the expected impact and WHERE clause. |
Include table names or domain terms when you know them. A prompt phrase such as ‘do not run it’ is not an execution control. To review data-changing SQL manually, verify that the project owner configured DML for the target schema as ‘Confirm before execution,’ then review its WHERE clause and expected impact.