Frequently Asked
Questions

Local AI runs a model on your own hardware: private, offline, and as fast as the machine it runs on. Live models are hosted, and handle larger schemas and harder questions. You can mix the two — stay local by default and reach for a live model only on the questions that need one.

PostgreSQL and MySQL. The schema layer reads the system catalog directly, so support is per-engine rather than per-version.

Refresh the connection and it re-introspects the catalog. Nothing is ever written back to your database: snapshots, embeddings and chat history live in SQLore’s own store, and your database is only ever read.

Queries run on your own database at your database’s speed — nothing is copied, exported or re-hosted. Generation speed depends on the model: a local one is bounded by your hardware, a live one by the round trip. Schema introspection happens once per connection, not once per question.

Not for the desktop app — it runs the whole engine locally, including the database connection. The server build exists for teams who want one shared instance.

It is commercial software, licensed per account rather than per seat: you pay for the questions you ask, not for users, rows or connections. The free plan has no expiry and no card, and the Pro trial runs once per device.

Your rows never are. When you use a live model, your schema and your question go to it so it can write the query; the query then runs against your own database and the results stay on your machine. On a local model nothing leaves your network at all.

No. Generated SQL is parsed to an AST and validated down to a single read-only SELECT before it goes anywhere near your database, then executed on a read-only connection with a statement timeout. That is a parser, not a blocklist of dangerous words. Read-only credentials are fully supported and recommended.

It introspects the database once and caches what it finds: tables, columns, keys, distinct values and statistics. Questions are matched against that index before any SQL is written, which is the difference between a plausible query and a correct one. You can also teach it your own rules — that "active" means status_id = 3 in your database, once.

It is agentic rather than one-shot: it links the right tables, writes the query, runs it, reads the result and corrects a bad join before you see anything. Every answer arrives with the SQL that produced it, the rows it returned and how long it took — because an answer you cannot check is an answer you cannot use.

Yes. Connect with read-only credentials, run entirely on a local model so nothing leaves your network, and self-host the server build if you want one shared instance instead of a desktop install per person. Every answer records the query it ran, which is usually what an audit is actually asking for.

One thing you ask. Answering it may take several model calls — linking the schema, writing the SQL, retrying after a bad join — and all of them are charged once, because anything else is impossible to explain on an invoice.

You keep access until the end of the period you have already paid for, then drop to the free plan. Nothing is deleted — connections, settings and history are all still there.