Yes — you can ask a real database a question in plain English and get back an answer you can trust. Type the question the way you'd ask a colleague, and the engine writes and runs an actual query against your PostgreSQL, MySQL, MongoDB, or Druid database — running inside your own private environment — then hands back an answer grounded in what the query actually returned, not a guess.
What "talking to your database" means
A database doesn't speak English, and most people who need an answer from one don't speak SQL. Talking to your database closes that gap: you type a question in ordinary language — "Which warehouses are running low on SKU-4021?" — and the system does the translation work a data analyst would normally do by hand. It reads the question against your actual schema, works out which tables or collections it needs, writes a real query, and runs it.
That's what separates this from a chatbot that "knows about" your data: the system isn't recalling a description of your database, it's connected to the database itself, and every answer is the direct result of a query executed against your live data at that moment.
How it works: question, query, answer
Under the hood, the loop is short, and it repeats every time you ask:
- Ask in plain English. No syntax, no table names, no query builder — just the question.
- Read the schema. The engine looks at the tables, columns, types, and relationships — or collections and fields, for a document store — that actually exist in your database.
- Write a real query. It generates SQL for a relational database, or the equivalent native query for a NoSQL store, expressing what you asked rather than paraphrasing it.
- Run it, read-only. The query executes against your database with read-only access, scoped to what that connection is allowed to see.
- Return the answer. Rows come back and are turned into a direct answer, usually with a chart, rather than a raw result set you have to interpret yourself.
If a query fails or comes back malformed — a misnamed field, a type mismatch — the engine detects it and retries, self-correcting up to three times before an error would ever reach you. Here's that loop end to end, against a live MongoDB collection:
MongoDB · support_tickets
{ $match: { created_at: { $gte: ISODate("2026-06-16") } } },
{ $group: { _id: "$account_id", tickets: { $sum: 1 }, avgResHrs: { $avg: "$resolution_hours" } } },
{ $match: { tickets: { $gt: 3 } } }
]);
Streaming keeps this loop feeling instant, not batch: answers return in seconds, not after a ticket filed with a data team.
SQL and NoSQL, handled the same way
The question you type is always plain English. What happens underneath depends on where your data actually lives, and the engine adapts to it:
- PostgreSQL and MySQL — relational tables. The engine writes real SQL: joins across tables, filters, aggregations, and window functions where the question calls for them. Our text-to-SQL guide covers this half in depth.
- MongoDB — a document store. There's no SQL to write, so the engine builds the right native query instead — a filter or an aggregation pipeline — against your collections. See our guide to querying MongoDB in natural language.
- Apache Druid — a real-time analytics store built for fast rollups over time. The engine writes queries suited to that shape: time-bucketed aggregations rather than row-by-row joins.
You never choose the query language, and you never write it yourself — the engine picks whatever fits the store. It's also why one Workbook can hold a Postgres source, a MongoDB source, and a spreadsheet side by side and still answer one question across all of them. See how on the connect your data page.
Running inside your own environment
Nothing about this requires exporting your database, standing up a copy, or piping rows into a separate analytics warehouse. You point tableArth.ai at the database running where it already runs — your own cloud account, your own VPC, your own on-prem network — with a connection scoped to read-only access. The question travels in, the query runs where your data already lives, and the answer travels back out. The data itself never has to move.
That matters for two reasons. Operationally, there's no pipeline to build or keep in sync — no nightly export job, no second copy of production data quietly drifting out of date. For security, a read-only, scoped connection means the natural-language layer can answer questions but cannot write, alter, or delete anything in your database. More on the connection model on the talk to your database page.
Trust: grounded, not guessed
The reason this is trustworthy rather than merely convenient comes down to one distinction: the answer is computed, not recalled. A language model asked to remember a fact about your data is guessing. A system that writes and runs a real query against your live database is reporting — the number came from an actual query execution, and you can see exactly which one.
That also makes answers checkable. If a number looks off, the query behind it is right there — the same one that ran — rather than a black box you're asked to take on faith. It's the difference between "the AI said so" and "here is the query, and here is what it returned."
What good requires
Writing a query from a sentence is the easy part. Making that trustworthy enough to put in front of real people, on a real production database, takes more:
- Schema awareness. The engine has to understand your actual tables, columns, types, and relationships — or collections and fields — to write a query that means what you asked, not a plausible-sounding approximation.
- Retry and self-correction. First-pass queries sometimes fail. tableArth.ai detects that and self-corrects up to three times before an error would ever reach you.
- Read-only, scoped execution. The connection can answer questions; it cannot write, alter, or delete. Access is scoped to what that connection is meant to see.
- Privacy controls. Plain-English questions about a production database still touch real data, so what the model sees needs to be your choice. tableArth.ai offers four privacy modes — Full AI, Masked data, Hybrid/stats-only, and a fully local template mode — set per database, workspace, or table. Details are on the security page.
- Suggested and clarifying questions. A blank box in front of a database you don't know the shape of isn't useful, so tableArth.ai suggests relevant questions to start from. When a question is genuinely ambiguous, it asks rather than guesses:
You: "best customers?"
tableArth.ai: "By revenue, retention, or lifetime value?"
That last step matters as much as query generation itself: an engine that guesses at an ambiguous question can return a confident, well-formatted, wrong answer, while one that asks gets to the right answer faster and keeps your trust in the process.
The throughline: talking to your database isn't about a model that sounds like it knows your data. It's a real query, written for the store you actually run, executed read-only where your data already lives, with the query itself always available to check. That's what makes a plain-English answer something you can act on.
Which databases can I talk to in plain English?
PostgreSQL, MySQL, MongoDB, and Apache Druid, running inside your own private environment. You ask a question in plain English and the engine writes and runs a real query against that database directly — SQL for the relational databases, the equivalent native query for MongoDB and Druid. More connectors are being added.
Do I have to move my data out of my database to ask questions?
No. The query runs where your data already lives, inside your own private environment. Nothing is exported, copied, or synced into a separate store just to answer a question.
Do I need to know SQL or write the query myself?
No. You ask in plain English and the engine writes the query for you, runs it, and returns the answer. You never have to see or write SQL, or the equivalent query for a NoSQL database, unless you want to.
How accurate and safe is it?
Answers are grounded in a real, read-only query run against your actual data, so they are verifiable rather than guessed. tableArth.ai detects a failed or invalid query and self-corrects up to three times before an error would ever reach you, and four privacy modes control exactly what the model can see.