AI Prompts for Data Analysts (2026)

Every prompt below works far better when you paste your **schema** — the `CREATE TABLE` statements or a column list with types — alongside your question. The model cannot guess your join keys or column names; give it the structure and it will write SQL that actually runs.

Be explicit about your SQL dialect (Postgres, BigQuery, Snowflake, MySQL) because functions and syntax differ. Replace every [bracketed] placeholder, and treat the first output as a draft: run generated SQL against a small sample or with a `LIMIT` before trusting aggregates.

**Do not paste real customer rows, PII, or confidential records into a chatbot.** Share schema and synthetic examples, not production data. This is both a privacy rule and a quality one — the model needs structure, not your real values.

Turn a question in English into runnable SQL. Always paste your schema first.

**1. Draft a query from a business question** — "You are a SQL expert writing [dialect, e.g. BigQuery] SQL. Here is my schema: [paste CREATE TABLE statements or column lists with types]. Business question: [plain-English question]. Write a single query that answers it. Use clear CTEs, alias tables, and add a one-line comment above each CTE explaining its purpose. State any assumption you made about the data (grain, join keys, null handling) in comments. If the question is ambiguous, write the most likely interpretation and note the alternative."

**2. Optimize a slow query** — "Here is a slow [dialect] query and its schema: [paste query] / [paste schema, including indexes if known]. Identify why it is likely slow (full scans, non-sargable filters, redundant joins, wrong grain) and rewrite it for performance while returning identical results. Explain each change in one line. Do not change the output columns or semantics. If a missing index would help, suggest the exact index DDL separately."

**3. Convert SQL between dialects** — "Convert this query from [source dialect] to [target dialect]: [paste query]. Preserve the exact result. Call out any function that has no direct equivalent and show the idiomatic replacement in the target dialect. Flag any behavior that differs (e.g. date handling, null sorting, integer division)."

Inherit a 200-line query with no comments? These make it legible and catch the bug.

**4. Explain an unfamiliar query** — "Explain this SQL query in plain English for a stakeholder who does not write SQL: [paste query]. Cover what question it answers, what each CTE or subquery contributes, the grain of the final result (one row per what?), and any filter that materially changes the answer. End with one sentence on a result the reader might misread, and why."

**5. Debug a query returning wrong numbers** — "This query returns numbers that look wrong: [paste query + schema]. Expected: [what I expected]. Got: [what I got]. Find the most likely cause — fan-out from a one-to-many join, double counting, a filter applied at the wrong stage, or null arithmetic. Explain the evidence and give the corrected query. Do not just reassure me it looks fine — assume there is a bug and find it."

Pick the right chart and produce a spec your BI tool or plotting library can consume.

**6. Recommend the right chart** — "I want to show [the relationship/comparison/trend I care about] from data with these columns and types: [list]. Audience: [executive / analyst / public]. Recommend the single best chart type and explain why in two sentences. Then list what goes on each axis, the encoding for any third dimension (color/size), the sort order, and the one thing to NOT do (e.g. dual axes, pie with 8 slices). Avoid chartjunk."

**7. Generate a chart spec** — "Produce a visualization spec for [tool: Vega-Lite / matplotlib / Plotly / Looker]. Data columns: [list with types]. Goal: [what the reader should take away]. Output the spec as code I can paste. Include a clear title that states the takeaway (not just the metric), axis labels with units, and an accessible color choice. Keep it to one chart — no dashboards."

**8. Write a chart caption and takeaway** — "Here is a description of a chart and its key values: [paste]. Write a one-line title that states the insight, a two-sentence caption explaining what to look at, and one cautionary note about what the chart does not prove. No hype, no causal claims unless I stated the data supports them."

Plan the cleaning before you run it, then turn results into something a stakeholder reads.

**9. Plan a data-cleaning workflow** — "I have a dataset with these columns and types: [list], and these known issues: [e.g. mixed date formats, nulls in X, duplicate IDs, inconsistent categories]. Produce a step-by-step cleaning plan: for each issue, the detection check (as SQL or pandas), the proposed fix, and the risk of that fix (what it might wrongly change). Order steps so earlier fixes do not break later checks. Do not auto-decide deletions — flag rows for my review instead."

**10. Summarize findings for stakeholders** — "Turn these analysis results into a stakeholder summary: [paste numbers / table / query output]. Audience: [role]. Write: a one-sentence headline finding, three bullet points with the supporting numbers, one caveat about data limitations, and one recommended next question to investigate. State correlation as correlation — do not imply causation unless I told you the data is experimental. Keep it under [N] words."

**Do not paste real PII or confidential rows.** Give the model schema and synthetic examples. Pasting production data is a privacy risk and rarely improves the SQL, which depends on structure, not values.

**Do not run generated SQL straight onto production aggregates.** A query that parses can still double-count from a fan-out join or apply a filter at the wrong stage. Test with a `LIMIT`, check row counts against a known total, and compare a sample against a hand-computed figure before trusting it.

**Do not let the model assert causation or invent numbers.** If it cites a figure you did not give it, that figure is fabricated. Ask it to state assumptions and to frame correlation as correlation. For the reasoning techniques that make these prompts reliable, see chain-of-thought prompting and how to write a system prompt. For a deeper model comparison, see the best AI chatbots compared.