The three power features of the AI Assistant for queries you already have.
For: developers.
When you have a query already, the AI can do three things with it. Each has a button next to the editor and a right-click menu entry. All three are also available by asking in plain English.
A short prose explanation, broken into the logical parts of the query. Example for:
SELECT u.country, COUNT(DISTINCT o.user_id) AS active_usersFROM users uLEFT JOIN orders o ON o.user_id = u.id AND o.created_at >= NOW() - INTERVAL '30 days'GROUP BY u.countryHAVING COUNT(DISTINCT o.user_id) > 10;
Returns something like:
This query counts unique users who placed at least one order in the last 30 days, grouped by their country.
The LEFT JOIN keeps users who haven't ordered, but the predicate on o.created_at means only orders from the last 30 days are joined. A user with no recent order joins to NULL.
COUNT(DISTINCT o.user_id) counts the active users per country, ignoring NULLs.
HAVING filters out countries with 10 or fewer active users.
Note: because the date filter is in the ON clause and not in the WHERE, users with no orders at all are still included in the country count (with active_users = 0).
The explanation is conversational and points out subtle behavior (the ON vs WHERE difference here is exactly the kind of thing that catches people).
Either a rewritten query, an index suggestion, or both. Examples:
Rewrite suggestion:
Your query uses SELECT * with a DISTINCT. Replacing DISTINCT with GROUP BY on the columns you actually need cuts the sort cost in half on your data size.
SELECT u.id, u.email, COUNT(o.id)FROM users u JOIN orders o ON ...GROUP BY u.id, u.email;
Index suggestion:
Your query scans orders filtering on (user_id, created_at). The current plan shows a Seq Scan with 800ms cost. Adding a composite index would let the planner use an Index Scan:
CREATE INDEX idx_orders_user_created ON orders (user_id, created_at DESC);
Expected speedup: 50–200x on this query.
The model knows about common patterns: N+1 in disguise (correlated subqueries that should be joins), missing indexes on FK columns, ORDER BY ... LIMIT without a matching index, OR clauses that prevent index use.
The optimize feature is opinionated. Some of its suggestions are wins; some don't help on your specific data; some change query semantics in subtle ways. Always:
Read the rewritten query carefully.
Run EXPLAIN ANALYZE on the suggestion before and after.
For index suggestions, weigh the cost (index size, write slowdown) against the speedup.
The AI cannot see your data distribution, only your schema and the plan output. Sometimes it suggests an index that helps cold queries but slows down high-volume writes.
The corrected SQL with a short note on what changed:
The error column "createdAt" does not exist occurs because PostgreSQL folds unquoted identifiers to lowercase. Your column is named created_at. Replacing createdAt with created_at fixes it.
SELECT * FROM users WHERE created_at > NOW() - INTERVAL '7 days';
Common errors the assistant handles well:
Error
Typical fix
Column doesn't exist
Casing, snake_case vs camelCase, missing alias
Ambiguous column
Add table prefix
GROUP BY clause
Add missing columns or wrap in aggregates
Type mismatch
Add cast
FK constraint violation
Suggest the parent row that's missing
Syntax error
Identify the malformed clause
The fix is generated against your live schema, so column suggestions are real, not guesses.