Read-only by construction
Layered connection, session, SQL and result controls keep LLMQuery on a governed enquiry path instead of allowing it to become an automation back door.
Governed answering for operational data
LLMQuery is a multi-layer AI and retrieval architecture—not an LLM wrapped around a database. We combine advanced retrieval, query decomposition, contextual reasoning, and data-layer techniques to produce answers with a level of precision and reliability that approaches research-grade question-answering systems.
The difference
LLMQuery is designed for organisations that need faster access to operational knowledge without turning a probabilistic model into an unchecked database operator.
Layered connection, session, SQL and result controls keep LLMQuery on a governed enquiry path instead of allowing it to become an automation back door.
Schema context, reviewed definitions and operating rules teach the system how your organisation names, counts and interprets its work.
The generated SQL, assumptions and source coverage stay attached so a reviewer can inspect how an answer was produced.
LLMQuery Connect can coordinate questions across current and legacy systems while preserving the contribution of each source.
Thirteen questions for every vendor
These are the practical differences buyers should verify before choosing a database-answering product. Ask us the same questions.
| No. | Question to ask | How LLMQuery differs |
|---|---|---|
| 01 | What exactly is sent to the AI provider? | Returned result rows stay local. LLMQuery makes the question, schema context and governed metadata boundary visible and inspectable. |
| 02 | Can one question reach more than one database? | LLMQuery Connect can coordinate one governed answer across databases while preserving source coverage and duplicate-risk rules. |
| 03 | Is this a language model pointed at a database, or something more? | Retrieval, query decomposition, local computation, validation and verification operate as distinct layers—not as a single prompt around a schema. |
| 04 | How does it learn what your organisation means? | Reviewed definitions, business rules, column notes and settled questions remain visible, editable and owned by the customer. |
| 05 | Does a second AI check a rule before it becomes permanent? | An optional different model can challenge a rule at rule-writing time, before that language begins steering future answers. |
| 06 | How was the accuracy figure measured? | The evaluation method, BIRD-SQL question set, scoring rules and failed cases are documented so buyers can examine the basis of the result. |
| 07 | What does it do when it is not sure? | LLMQuery can refuse or qualify an answer when joins, filters, source coverage or result conditions cannot be verified. |
| 08 | Can it write to your database? | No. Read-only controls operate across the connection, session, generated SQL and returned-result layers. |
| 09 | Where does it run, and what does the vendor see? | The application runs locally. Alchemy Loop is not in the query path and does not receive installation telemetry or database results. |
| 10 | Can common questions bypass the LLM entirely? | DBAs can save direct SQL for common questions, eliminating repeat LLM calls and provider-token costs. LLMQuery tallies frequently asked questions and alerts the DBA when a recurring question is a strong candidate for approved SQL. |
| 11 | Can a knowledgeable user scope the question to specific tables? | Table Scoping lets an advanced user type @, select a known table, and receive recommendations for the supporting tables most likely to be needed. |
| 12 | Does the built-in help understand the task being performed? | Context-aware help is briefed on the current workflow and decision without receiving database rows, values or the text of a refused question. |
| 13 | Can it answer questions on a system that keeps its fields as rows? | LLMQuery identifies the file, question, answer and form columns in entity-attribute-value structures, keeps matching field numbers from different forms separate, and states when the platform’s field dictionary is still required. |
A multi-layer system
Each layer narrows uncertainty before an answer reaches the user. The model helps plan; deterministic controls govern execution; local diagnostics make the result easier to challenge and verify.
Profile schemas, relationships, definitions and relevant operating context.
Break complex questions into controlled, database-aware reasoning steps.
Validate and run read-only SQL in each database's own dialect.
Check joins, filters, empty results, source coverage and answer assumptions.
Return a concise response with its evidence and audit trail attached.
Built for accountable teams
Reduce the wait for custom reports while keeping questions inside a governed, reviewable process.
Add natural-language access without surrendering read-only boundaries, database-specific controls or technical traceability.
Review what was asked, what ran, what sources contributed and what assumptions shaped the answer.
Technical evidence
Use the briefs below to examine the product model, multi-database approach, technical maturity and benchmark context.
Ask every vendor the same thirteen questions, including us.
Download the checklist ↓A governed path to operational answers