Write a SELECT Query
Turn a plain-language request into a SELECT query given your schema.
Prompt template
Write a {{dialect}} SELECT query for the following request, using only the tables and columns in the schema below. Explain any join or filter choice you made in one line.
Schema:
{{schema}}
Request:
{{request}}
Placeholders
{{dialect}} — SQL dialect- Database engine/dialect to target. Example: PostgreSQL
{{schema}} — Schema- Relevant table and column definitions. Example: orders(id, customer_id, total_cents, created_at)
customers(id, email, country)
{{request}} — Request- What you want the query to return. Example: Total revenue per country for orders placed in the last 30 days.
Example input
dialect: PostgreSQL · schema: orders + customers tables · request: total revenue per country, last 30 days.
Filled-in example
Write a PostgreSQL SELECT query for the following request, using only the tables and columns in the schema below. Explain any join or filter choice you made in one line.
Schema:
orders(id, customer_id, total_cents, created_at)
customers(id, email, country)
Request:
Total revenue per country for orders placed in the last 30 days.
Expected output format
A single SQL query block plus a short explanation of any join, filter, or aggregation choice.
Customization tips
- Paste your actual CREATE TABLE statements for the most accurate column names and types.
- Specify pagination or row limits if the result set could be large.
Limitations
- The assistant can't see your real data, so it cannot guarantee performance or catch data-quality issues (nulls, duplicates).
- Column and table names must be provided accurately — the assistant will not guess a schema it wasn't given.
Safety notes
- Never paste real customer data, only schema (structure), when asking for query help.
- Run new queries against a read replica or staging database before using them on production.
Explain a Query
Get a plain-language explanation of what an existing query does, step by step.
Prompt template
Explain what the following {{dialect}} query does, step by step, in plain language. Note any part that could be slow or risky (e.g. missing index usage, unbounded result set, implicit type conversion).
Query:
{{query}}
Placeholders
{{dialect}} — SQL dialect- Database engine/dialect. Example: MySQL
{{query}} — Query- The SQL query to explain. Example: SELECT u.id, COUNT(o.id) FROM users u LEFT JOIN orders o ON o.user_id = u.id WHERE u.created_at > '2025-01-01' GROUP BY u.id HAVING COUNT(o.id) = 0;
Example input
dialect: MySQL · query: users with zero orders since 2025-01-01.
Filled-in example
Explain what the following MySQL query does, step by step, in plain language. Note any part that could be slow or risky (e.g. missing index usage, unbounded result set, implicit type conversion).
Query:
SELECT u.id, COUNT(o.id) FROM users u LEFT JOIN orders o ON o.user_id = u.id WHERE u.created_at > '2025-01-01' GROUP BY u.id HAVING COUNT(o.id) = 0;
Expected output format
A step-by-step plain-language explanation, followed by a short list of potential performance or correctness risks.
Customization tips
- Paste the actual EXPLAIN/EXPLAIN ANALYZE output alongside the query for a more concrete performance discussion.
- Ask specifically "could this return unexpected NULLs?" if you suspect a join issue.
Limitations
- Without real table statistics, performance notes are general guidance, not a guaranteed query plan.
Safety notes
- If the query touches sensitive tables, avoid pasting real row-level data — schema and the query text are usually enough.
Optimize a Slow Query
Get suggestions to speed up a slow query, with reasoning for each suggestion.
Prompt template
Suggest ways to optimize the following {{dialect}} query for performance. For each suggestion, explain the trade-off (e.g. added index maintenance cost, readability). Do not change the query's result set.
Schema and existing indexes:
{{schema}}
Query:
{{query}}
Placeholders
{{dialect}} — SQL dialect- Database engine/dialect. Example: PostgreSQL
{{schema}} — Schema and indexes- Relevant tables, columns, and current indexes. Example: orders(id PK, customer_id, status, created_at) — index on customer_id only
{{query}} — Query- The slow query to optimize. Example: SELECT * FROM orders WHERE status = 'pending' ORDER BY created_at DESC LIMIT 50;
Example input
dialect: PostgreSQL · schema: orders table, index on customer_id only · query: filter by status, order by created_at, limit 50.
Filled-in example
Suggest ways to optimize the following PostgreSQL query for performance. For each suggestion, explain the trade-off (e.g. added index maintenance cost, readability). Do not change the query's result set.
Schema and existing indexes:
orders(id PK, customer_id, status, created_at) — index on customer_id only
Query:
SELECT * FROM orders WHERE status = 'pending' ORDER BY created_at DESC LIMIT 50;
Expected output format
A list of specific optimization suggestions (e.g. composite index, avoiding SELECT *), each with a brief trade-off note.
Customization tips
- Share current row counts per table so suggestions are proportionate to your actual scale.
- Ask for the suggestions ranked by expected impact vs. implementation effort.
Limitations
- Real optimization requires testing with EXPLAIN ANALYZE on your actual data — suggestions here are a starting point, not a guarantee.
Safety notes
- Test new indexes on a staging environment first; adding indexes can affect write performance and storage.
Convert a Question to SQL
Translate a plain-English analytics question into a runnable query.
Prompt template
Convert this question into a {{dialect}} query using only the schema below: "{{question}}"
Schema:
{{schema}}
If the question is ambiguous, state your assumption before the query.
Placeholders
{{dialect}} — SQL dialect- Database engine/dialect. Example: BigQuery Standard SQL
{{question}} — Question- The plain-English question to convert. Example: Which product category had the biggest month-over-month growth in units sold last quarter?
{{schema}} — Schema- Relevant tables and columns. Example: sales(id, product_id, units, sold_at)
products(id, category)
Example input
dialect: BigQuery Standard SQL · question: category with biggest month-over-month growth last quarter · schema: sales + products tables.
Filled-in example
Convert this question into a BigQuery Standard SQL query using only the schema below: "Which product category had the biggest month-over-month growth in units sold last quarter?"
Schema:
sales(id, product_id, units, sold_at)
products(id, category)
If the question is ambiguous, state your assumption before the query.
Expected output format
A stated assumption (if the question was ambiguous), followed by a single runnable query.
Customization tips
- If the question is genuinely ambiguous, ask for two interpretations and their queries side by side.
- Specify the exact date range or fiscal calendar definition if "last quarter" is ambiguous for your business.
Limitations
- Ambiguous business terms (e.g. "active user", "churn") need a precise definition — the assistant will guess otherwise.
Safety notes
- Confirm the generated query's date logic and definitions match your actual business rules before trusting the output for reporting.
Write a Schema Migration
Draft a migration script for a schema change, including a rollback plan.
Prompt template
Write a {{dialect}} migration to {{change_description}}. Include: (1) the forward migration, (2) a rollback/down migration, and (3) any data backfill needed. Call out anything that could lock the table or cause downtime on a large table.
Current schema:
{{schema}}
Placeholders
{{dialect}} — SQL dialect- Database engine/dialect. Example: PostgreSQL
{{change_description}} — Change description- What the migration should do. Example: add a NOT NULL 'status' column with a default of 'active' to the accounts table
{{schema}} — Current schema- The relevant current table definition. Example: accounts(id PK, name, created_at)
Example input
dialect: PostgreSQL · change_description: add NOT NULL status column with default · schema: accounts table.
Filled-in example
Write a PostgreSQL migration to add a NOT NULL 'status' column with a default of 'active' to the accounts table. Include: (1) the forward migration, (2) a rollback/down migration, and (3) any data backfill needed. Call out anything that could lock the table or cause downtime on a large table.
Current schema:
accounts(id PK, name, created_at)
Expected output format
A forward migration script, a rollback script, any needed backfill step, and a note on locking/downtime risk for large tables.
Customization tips
- Mention your table's approximate row count so the assistant can flag lock/downtime risk appropriately.
- Ask for the migration split into safe, incremental steps if the table is very large or high-traffic.
Limitations
- Locking behavior varies by database version and configuration — verify against your specific database's documentation before running on production.
Safety notes
- Review every migration for destructive operations (DROP, DELETE, TRUNCATE) and always test on staging with a recent backup before running on production.
- Never run an unreviewed migration script directly against a production database.