Skip to main content

Prompting effectively

The cost of a vague prompt isn't just a vague answer — it's a wrong query, run against a real database, that you may or may not catch. This page covers patterns that consistently produce accurate answers and the anti-patterns that cause confusing ones.

Three things every prompt should pin down​

When in doubt, your prompt should answer:

  1. What metric (or set of metrics) you want — revenue, count of customers, 95th percentile latency.
  2. Over what time range — Q3 2024, last 30 days, fiscal year 2025.
  3. Sliced how — by region, by product category, by signup cohort.

Not every prompt needs all three (a global "How many customers do we have?" doesn't need a slice), but most do. Skipping a dimension is the #1 cause of "QRY answered something I didn't ask".

✅ Good — concrete and specific​

Show me total revenue by product category for Q3 2024.
List the 20 customers with the highest lifetime value who haven't
purchased in the last 90 days.
Compare this month's signup rate to the same month last year, broken
down by acquisition channel.

❌ Vague — surfaces of these patterns to avoid​

Show me sales data.

Which sales? What time range? At what grain?

What happened recently?

"Recently" is undefined. Yesterday? Last quarter?

Get all the customer info.

"All" of a million-row table is a query you don't want.

Patterns that work​

Iterate, don't restart​

A conversation has memory. Start broad, refine in follow-ups:

You: Show me revenue trends.
QRY: [shows a global revenue line chart]
You: Break that down by region.
QRY: [shows the same with region as the colour series]
You: Focus on the West region.
QRY: [zooms to West only]
You: What's driving the spike in March?
QRY: [drills into that period]

Each follow-up builds on the previous answer. You don't repeat the time range, the metric, or the schema — QRY knows.

Reference table names when you know them​

If you know the table:

Plot transaction_amount over time from the orders table, by month.

beats:

Plot revenue by month.

…because the second leaves QRY to guess which table holds the metric.

Ask for the chart type you want​

QRY picks a default chart based on the data shape, but you can override:

Make this a line chart, with months on the X axis and revenue on Y.
Show this as a horizontal bar chart sorted descending.
Switch to a stacked area chart with category as the stack.

Explore before you query​

When you don't know the schema, ask QRY to show you around:

What tables do we have here?
Describe the structure of the customers table.
Show me 5 sample rows from orders.

This is faster than guessing table names — and QRY knows your schema better than you do across 40+ tables.

Constrain volume​

You almost never want a query against millions of rows with no filter. Help QRY not do that:

…limited to the last 30 days
…top 100 by revenue
…sample 10 rows

Anti-patterns​

Pseudo-SQL when natural language works​

Don't try to write SQL in English:

SELECT SUM(revenue) FROM sales WHERE date >= '2024-01-01' GROUP BY category.

Just say:

Total revenue by category in 2024.

QRY writes the SQL. That's the whole point.

Mixing topics in one conversation​

A conversation has memory but it's not a swiss-army knife. If you switch from "customer churn" to "warehouse logistics", start a new conversation. Conversation context that's irrelevant to the new question can subtly steer QRY's interpretation.

"All the data"​

Don't ask for everything. Even a SELECT * with no filter is a problem at scale; with joins it's a problem at small scale too. Always bound by time, by limit, or by filter.

When a result looks wrong​

Open the Processing Details of the answer and read the SQL QRY actually ran. Most "wrong" answers come from:

  • A reasonable SQL query that targets the wrong column (e.g. created_at when you meant updated_at).
  • A reasonable interpretation of an ambiguous time range ("January" → which year?).
  • A schema misunderstanding (QRY picked the staging table when you meant the prod one).

All three are fixed by adding a sentence to your prompt:

Use the customers_v2 table, not customers, and filter by created_at not updated_at.

See also​

QRYA product of IXEN.