Asking your database a question

Data Analyst connects to PostgreSQL, MySQL and others, turns a question in plain language into SQL, runs it, and draws the result as a bar, line, pie, area or scatter chart. It keeps a query history, lets you save the ones you repeat, and shares them with named collaborators.

People try it, get one wrong answer, and conclude it does not work. Almost always the problem is the same, and it is not the model.

Narrow the schema before you ask

The schema explorer shows your tables and how they relate. Use it to point the question at two or three tables rather than the whole database.

This matters more than any prompt wording. A schema with 90 tables contains four things that could plausibly be called "revenue", and the model has to guess which one you meant. A schema narrowed to orders and order_items has one. The narrower question is cheaper, faster and correct — in that order of importance.

Say what you mean by the words you use

Your database does not know what your company means by "active customer". Say it: customers with at least one order in the last 90 days. That single clarification removes the most common category of wrong answer, which is not a broken query but a correct query answering a different question.

Ask compound questions in one go rather than in stages. "Revenue by region for Q3, and flag anything more than 15% below plan" is one operation. Asking for revenue, then regions, then outliers is three, costs three times the tokens, and the third answer is usually worse because the context has drifted.

Read the SQL, at least once

Data Analyst shows the query it generated. Read it the first time you ask anything you will act on.

You are checking two things: does it join what you expected, and does the date range mean what you think. Those are where a plausible-looking wrong answer comes from. A total that is 8% off because a join dropped rows looks exactly like a correct total.

Once a query is right, save it. A saved query is the version you trust, and running it next month is free of the risk that a rephrased question produces different SQL.

The chart is a summary, not the finding

Pick the chart type for the shape of the question: line for change over time, bar for comparison between categories, scatter when you are looking for a relationship. A pie chart with nine slices communicates nothing and is usually a bar chart that gave up.

And when you share a result with a colleague, share the saved query rather than a screenshot of the chart. The chart is a picture of one moment; the query still answers the question next quarter.