Generate the query, explain the one you inherited, and find out why the other one takes forty seconds — without leaving the schema you are working in.
Writing SQL is the job people name, and it is the one they spend the least time on. The hours go to the other two: understanding a query someone left behind, and working out why a query that used to be fine no longer is.
A model asked for "revenue by region last quarter" with no schema will invent a `revenue` column and a `region` table, because that is what the question implies. Grounding is the entire game. SQLore retrieves the relevant slice of your schema — the tables, the foreign keys between them, and the distinct values in the columns you are likely filtering on — and puts that in front of the model before it writes anything. The query comes back referencing `orders.total_cents` and a join through `customers` because those are the names that were actually available.
One-shot generation has no feedback. SQLore is agentic: it writes the SQL, executes it read-only, reads the result, and if the result is obviously wrong — zero rows where there should be thousands, a join that fanned out and multiplied the totals — it revises and runs again. You see the query that worked, not the three that did not.
Every database has vocabulary that is not in the column names. If "active" means `status_id = 3` in your system, you tell it once and it holds. That is the difference between an assistant that is impressive in a demo and one that is correct on the fourth Tuesday of using it.
More answers on the main FAQ, or ask us directly.
The technique
For analysis
The category, explained
Every page in this section covers a different question about the same product. See all solutions.
Start free, upgrade when you are asking enough questions for it to matter.
