Ask a question, get rows and the query behind them. It reads your real schema first, so the answer references your tables rather than plausible-sounding ones.
MySQL exposes its metadata through `information_schema`, and SQLore reads it directly on first connection rather than working from a description of your database supplied by hand.
You ask for orders by month; then you want it by channel, excluding refunds, for the current financial year. Each refinement builds on the query already established rather than starting over — which is the whole reason a chat interface beats a query box for exploratory work.
Every generated statement is parsed to an AST and validated to a single read-only SELECT before it is executed, on a read-only connection with a statement timeout. Create a MySQL user with `GRANT SELECT` and nothing else, point SQLore at that, and the guarantee holds at the server as well — which is the configuration to use against anything you care about.
Identifier quoting, `ONLY_FULL_GROUP_BY`, collation rules that decide whether a comparison is case-sensitive, and a materially different set of window and CTE capabilities depending on version. Because introspection is per-engine rather than generic, the SQL comes back in the dialect your server will actually accept instead of Postgres SQL with the quotes changed.
`GRANT SELECT` on the databases you want reachable. Optional, but it is the configuration we recommend for anything in production.
Host, port, database and that user. Credentials stay on your machine.
It reads information_schema once and caches the result locally, then builds the retrieval index over it.
Plain English in, rows and SQL out. Follow-ups narrow the answer rather than restarting it.
More answers on the main FAQ, or ask us directly.
MySQL, in depth
PostgreSQL
The interface
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.
