Ask the Warehouse in Plain English — and Verify Before You Believe

Workflow area: Data & Evidence · Tier: Foundation · Hands-on time: ~25 minutes

Analysts who can pull their own numbers ask ten times more questions, and better ones. Snowflake Cortex, BigQuery's Gemini assistance, and a general LLM given your schema all generate workable SQL from plain English now. The failure mode is not syntax — generated queries almost always run. It is silent semantic error: the wrong date column, a join that duplicates rows, a missing status filter that counts cancelled records. A query that runs and returns a confident wrong number is more dangerous than one that fails, because wrong numbers travel into decks and decisions. Verification is not optional overhead; it is the skill.

When to use — and when not to

• Use it for evidence questions in analysis workvolumes, cycle times, segment splits, trend checks — where waiting for a data-team ticket would mean not asking at all.
• Use it to sharpen requirements with facts"how many orders actually hit this exception path?" turns a design debate into a data lookup.
• Use it on warehouses you have legitimate read access tosanctioned self-serve, not credential-borrowing.
• Skip it for numbers going into financial or regulatory reportingthose belong to governed, certified pipelines; self-serve SQL is for analysis, not the audited books.
• Skip it when you cannot see the schematext-to-SQL without table and column context guesses names, and guessed SQL is fiction that parses.
• Skip complex multi-fact joins on your first weekstart with single-table and two-table questions until your verification instincts calibrate.

The recipe

1. 1.

   Assemble schema context once. Export or copy the relevant table definitions: table names, column names and types, and — critically — the tribal knowledge: which date column means what, what status values exist, known data quirks. If your warehouse has a data catalog or dbt docs, pull descriptions from there. Save this as your standing "schema pack".

2. 2.

   Ask with context, and demand explainable SQL. In Snowflake Cortex Analyst or BigQuery's Gemini pane, the schema is already known — go straight to the question. With a general LLM:

   Copy

   You write SQL for analysts. Dialect: [Snowflake / BigQuery /
   Postgres].
   Schema:
   [PASTE TABLE DEFINITIONS + NOTES, e.g. "orders.created_at = order
   placed; orders.completed_at = fulfilled; status values: placed,
   fulfilled, cancelled, test — EXCLUDE test in all analysis"]
   
   Question: [PLAIN-ENGLISH QUESTION — e.g. "monthly count of new
   vendors onboarded in 2025, split by region, excluding rejected
   applications"]
   
   Output:
   1. THE QUERY — formatted, with a comment on every filter and join
      explaining why it is there.
   2. ASSUMPTIONS — every choice you made that the question did not
      specify (which date column, which statuses included, how ties
      or duplicates are handled).
   3. SANITY CHECKS — two quick follow-up queries I can run to
      validate this result (e.g. total without grouping, count of
      excluded rows).
   
   Rules: if the schema does not clearly contain what I asked for,
   say so and ask — do not guess column meanings.
   

3. 3.

   Read the SQL before running it. You are not checking syntax — you are checking meaning, and this review is the human gate, not a formality. Four questions: Is it the right date column for what I asked? Are the status/type filters right — what is being silently included or excluded? Could any join multiply rows? Is the grain what I think it is (one row per vendor, or per application)? The ASSUMPTIONS section is where the model confesses; read it every time.

4. 4.

   Cross-check against a known-good number. Before using any result, reconcile it once against something already trusted: last month's board pack, a certified dashboard, the ops team's own tracker. Exact match, or an explicable difference ("dashboard includes test records") — either is fine. An unexplained difference stops the work until resolved. A sample verification note worth keeping:

   Copy

   Result: 1,847 vendors onboarded in 2025 H1.
   Cross-check: Q1 board pack reports 912 for Q1; my query gives 914
   for Q1. Difference: 2 vendors with region NULL, excluded from the
   board pack's regional table. Explained. Using 1,847 with note.
   

5. 5.

   Save the question, the SQL, and the verification together. Paste all three into your analysis notes. When the number is challenged in a review — and good numbers get challenged — you reproduce it in one minute. Unreproducible numbers die in meetings, and deserve to.

Make it yours

• Snowflake Cortex Analyst / BigQuery Gemini: prefer the in-warehouse assistant when you have it — it sees real schema and real metadata, and access controls apply automatically. Keep the same read-the-SQL and cross-check habits; in-warehouse assistants make the same semantic guesses.
• Claude with your schema pack: for warehouses without a native assistant, a Project holding your schema pack plus the quirks list becomes your standing SQL desk — and it explains existing queries too, which is half the job when inheriting someone's dashboard.
• The semantic-model shortcut: if your team maintains a dbt semantic layer or Cortex Analyst semantic model, route questions through it — pre-defined metrics kill the wrong-date-column class of errors entirely.
• Team scale: share the schema pack and the quirks list in the team wiki; every analyst's generated SQL improves, and the quirks list ("always exclude test records") becomes enforced tribal knowledge.

Quality check

• You read every line of the SQL and could explain ita query you cannot explain is a number you cannot defend.
• The assumptions were reviewed, not skimmedthe wrong-date-column error lives in the assumptions, and it is the most common miss.
• One cross-check against a known-good figure passedor the difference is documented and explained.
• Row-multiplication was ruled outrun the no-grouping total as a sanity check; joins that fan out inflate everything downstream.
• Excluded records are knownyou can say what the filters dropped and why; silent exclusions are how "total" becomes "some".
• The evidence trail existsquestion, SQL, result, and verification note stored together, reproducible on demand.