SQL Optimizer
AI-driven SQL rewrite plus a separate SQL safety checker.
RaiseDB has two distinct things that show up in this area — the AI optimizer and the SQL safety checker. They are independent and both worth knowing.
AI Optimizer
What it does
Sends your SQL, the schema context, and the engine dialect to the model. Asks for a rewritten query that:
- Returns the same result set
- Follows the engine's dialect
- Uses indexes / joins appropriately
- Avoids
SELECT *, prefers CTE over correlated subqueries where sensible
Trigger
In the AI panel, type /optimize. There's no toolbar shortcut in the SQL editor for the AI optimizer (the toolbar's wand button is the SQL formatter, not the AI optimizer).
Output
Optimized SQL in a fenced block + a written explanation of what changed. Like NL→SQL, it's run through the safety checker before display.
SQL Safety checker
A local, deterministic, AST-based check. No AI call. Always available.
What it flags
| Pattern | Severity |
|---|---|
SELECT INTO | Dangerous |
UPDATE without WHERE | Dangerous |
DELETE without WHERE | Dangerous |
DROP (and any nested) | Dangerous |
TRUNCATE | Dangerous |
ALTER | Dangerous |
| Multiple statements | Needs confirmation |
| Updating / deleting system catalog | Dangerous |
| Parse failure | ParseError |
The result is one of Safe / NeedsConfirmation / Dangerous.
Trigger
- In the SQL editor toolbar: the shield button
- In the AI panel:
/safety - Automatically applied to anything the model generates
Dialect-aware
check_sql_safety_dialect accepts the engine's SQL dialect, so PostgreSQL $$, MSSQL [], MySQL backticks parse correctly. Default enums are declared but only the implemented AST branches produce issues — don't expect separate ContainsDrop / ContainsTruncate / GenericDeleteWithoutWhere variants from the current implementation.
When you don't want AI
The safety checker is purely local. Run it on any SQL you've pasted, AI-written or not.