Chat with your database in plain English
and check every answer against the query that produced it
Datarelix lets you ask a database a question in plain English. It reads your schema, turns the question into a read-only SQL query, checks that query against a validator that rejects anything that is not a read, and runs it against your live data. The answer arrives with the query that ran, the tables it read, the row count, and the runtime, so you can check it. Useful answers can be pinned to a dashboard that refreshes.
What you can ask, and what comes back
You ask the question the way you would ask a colleague. What comes back is a table or a chart, and underneath it, the evidence: the query, its sources, and what it cost to run.
- the query
- the exact SQL that ran, not a paraphrase of it
- the tables
- which sources it read, so you can spot a staging copy
- the row count
- how many rows came back
- the runtime
- how long the query took on your database
The mechanism behind the translation — schema context, a structured plan, validation, then execution — is set out in how a plain-English question becomes SQL.
customers · orders · 10 rows · 0.4s
Is it safe to point an AI at your database?
It depends entirely on what enforces the read-only promise. A system prompt telling a model not to write is a request, not a control. In Datarelix, every generated statement is parsed into a syntax tree and rejected unless it is a read, and the model never holds the credential — an isolated query service does, and it decrypts it only at the moment a query runs. Generated Python analysis runs in a sandbox with no network path out, enforced at the network layer rather than by a code check.
The architecture and its residual risks are laid out in the read-only threat model and the controls that enforce it, the credential path in where your database password lives, and what the model receives instead, and the canonical statement of every boundary on the security page.
Evaluating vendors rather than just us? The vendor-neutral security checklist is ten pass/fail questions and the artifacts worth demanding, written to be used against anyone in this category.
Will the answer be right?
Sometimes it will not be, and the useful question is whether you can tell. A query can be syntactically perfect, run without error, and still measure the wrong thing: it can read "revenue" as gross when your board means net, or multiply an order total across line items in a join. No amount of confidence language fixes that. Showing the query does.
Two things move the odds. The first is context: a model that knows what your
status
column means writes a different filter than one that does not —
why a tool picks the wrong column, and which columns to describe first.
The second is a habit of checking, which takes about a minute once you know where to look:
the eight-step check before a number reaches the board.
What it connects to
Datarelix queries the databases, warehouses, and object storage you already run, rather than asking you to move data somewhere new — the current list is on the features page. Connections are read-only by design, and scoped to the schemas you point them at.
Engine-specific guides cover the grants to create, the gotchas that bite, and where each engine's own behaviour shows up in generated SQL: ask PostgreSQL questions in plain English, ask Snowflake questions in plain English, query BigQuery in plain English, and ask MySQL questions in plain English.
Where this sits next to your BI tool
Beside it, not instead of it. A metric that fifty people read the same way every Monday belongs in a certified dashboard, where the definition is governed and the number is stable. Conversational analytics is for the other half: the question nobody anticipated, asked once, that would otherwise become a ticket. The split follows how often a question repeats and how many people need the same answer — a decision framework for AI analytics and traditional BI.
If the goal is to shorten the request queue without re-platforming anything you already own, the overlay pattern describes what stays governed and what moves.
How this differs from a chatbot that summarises a spreadsheet
Plenty of tools answer data questions in plain language. They divide on where the answer comes from. Some answer from text — a pasted export, a document, the model's trained associations — and produce prose that cannot be traced to anything. Others run a query against your live database and hand you the query with the result. Only the second kind can be checked, which is the whole of the difference and the reason we call it verifiable conversational analytics.
The category, its four evidence layers, and a buying checklist are in what verifiable conversational analytics means. Every guide referenced on this page is listed on the resources hub.
Common questions
- Do I need to know SQL?
- No. You ask in plain English. The SQL is shown so that someone who reads SQL can check it — reading it is optional for asking, and necessary before a number goes somewhere consequential.
- Can it change or delete my data?
- No. Every generated statement is parsed into a syntax tree and rejected unless it is a read, before anything reaches your database. Connect it with a read-only database user as well, so the boundary is enforced on both sides.
- Does the AI see my data?
- The model receives your schema structure — table and column names, types, keys, and any descriptions your team writes — not your rows. One honest exception: when an answer is a single value, that value carries into follow-up context so "and how does that compare to last year?" resolves. Result tables do not.
- Where does my database password go?
- Not to the model. The credential is encrypted at rest, held on the execution side, and decrypted only at the moment a query runs.
- What if the answer is wrong?
- Then the evidence is how you catch it. A query can run cleanly and still measure the wrong thing — the wrong revenue definition, a join that multiplies rows — which is why the query and its sources ship with every answer rather than a confidence score.
- Does this replace our BI tool?
- No, and it should not. Certified dashboards are the right home for a metric that many people read the same way every week. This is for the questions that arrive once and cannot wait.
Ask one question you already know the answer to.
It is the fastest way to find out whether a tool understood your schema — connect a read-only user, ask, and read the query it wrote.
14 days at Pro limits · no credit card required