Yes — you can query MongoDB in plain English. Ask a question about a collection the way you'd ask a colleague who knows the data, and tableArth.ai reads your collections, writes the MongoDB query or aggregation pipeline the question actually needs, runs it against your database, and returns a grounded answer and a chart. No aggregation framework to learn, no pipeline to hand-write, no exporting documents to a spreadsheet first.
That matters because MongoDB doesn't play by SQL's rules. It's a document database, and the questions people actually ask — "average order value by category," "which customers churned" — don't map onto it the way they map onto a relational table. Below is what makes MongoDB harder to query by hand, what asking it in natural language actually means, and how tableArth.ai grounds the answer in a real query run against your own environment.
Why MongoDB is harder to query
A relational database stores rows in tables with a fixed set of
columns, and SQL was built for exactly that shape —
SELECT, JOIN, and GROUP BY
all assume rows and columns you can name up front. MongoDB stores
documents: JSON-like objects that can nest
sub-documents and arrays, and whose shape can vary from one
document to the next inside the same collection. There is no
fixed schema to read off a table definition, and there is no
SQL. Instead, MongoDB has its own query language — a filter
syntax for simple lookups, and the aggregation
framework for anything that needs computing, joining, or
reshaping: a pipeline of stages such as $match,
$group, $unwind, and
$lookup, each one transforming the output of the
last.
That difference shows up the moment someone has a real question. "Average order value by category last quarter" sounds simple, but against MongoDB it means knowing which collection holds orders, whether line items sit in a nested array on each order document, how to unwind that array before you can group by category, and which operators do the summing. It's a different syntax, a different mental model, and a genuinely steeper learning curve than SQL for most business users — and for plenty of engineers who are perfectly comfortable with SQL but rarely touch Mongo's aggregation framework by hand. In practice, most "quick" questions against MongoDB become a script somebody writes once, an export to a spreadsheet, or a ticket that sits in a queue.
What natural language querying of MongoDB means
Natural language query, or NLQ, for MongoDB means asking a plain-English question about a collection and getting a computed answer back — without writing a filter, a pipeline, or an operator yourself. tableArth.ai reads the actual shape of your collections: the fields, nested sub-documents, arrays, and types present in your documents, not a fixed schema someone wrote down and forgot to update. From that, it decides what the question needs — a simple filter for a straightforward lookup, or a full aggregation pipeline when the question involves grouping, joining across collections, or computing over a nested array.
The input side doesn't change based on the database. Ask tableArth.ai a question about a PostgreSQL table and the engine writes SQL. Ask the same kind of question about a MongoDB collection and it writes a Mongo query or aggregation pipeline instead. You experience one consistent thing — a question box and an answer — while the platform handles the fact that SQL and MongoDB's aggregation framework are, underneath, two different languages solving the same problem for two different storage models.
How it works: question, aggregation, answer
Under the hood, asking MongoDB a question in plain English follows a short pipeline of its own:
- Natural language in. You ask a question the way you'd ask a colleague — no field names, no operators, no pipeline syntax.
- Question to query or aggregation. tableArth.ai reads the question against your collections' real structure and writes the MongoDB query it needs — a simple filter, or a multi-stage aggregation pipeline that matches, unwinds, groups, joins, and sorts.
- Run it, read-only. The query runs directly against your MongoDB database, inside your own private environment, respecting whatever access rules already apply.
- Return a readable answer. The resulting documents come back and are turned into a concise answer, not a raw cursor of JSON.
- Auto chart. The system picks the visual that fits the answer — a bar chart for a category comparison, a line for a trend, a table when the detail matters.
With tableArth.ai this whole loop is the product: the engine is schema-aware, streams the answer back in under five seconds, self-corrects a failed or invalid query up to three times before anything reaches you, and auto-selects a chart across bar, line, area, pie/donut, scatter, stacked bar, funnel, and table. Here's what that looks like end to end, from a plain-English question to a generated aggregation stage:
MongoDB · orders
{ $unwind: "$lineItems" },
{ $group: { _id: "$lineItems.category", avgValue: { $avg: "$lineItems.price" } } }
]);
Nested documents and collections
MongoDB documents nest data by default. An order document might carry a customer sub-document, a shipping address, and an array of line items, each with its own product reference — all inside one document, with no separate "line items" table to join. A flat, row-and-column mental model breaks here: "revenue by product" isn't a column anywhere; it's a value you'd have to pull out of an array on every single order.
tableArth.ai reads that nested structure as part of your schema —
which fields are sub-documents, which are arrays, and how one
collection references another — the same way it reads foreign keys
in a relational database. When a question depends on a nested
field, or needs an array flattened before it can be grouped or
summed, the engine writes the $unwind,
$lookup, or nested $project stages the
question needs automatically. You still just ask about "orders" or
"customers" in plain English; the shape of the underlying
documents isn't something you have to reason about.
The same goes for questions that span more than one collection.
Ask something that needs both your orders and
customers collections, and tableArth.ai works out the
relationship and writes the $lookup stage that joins
them — the Mongo equivalent of a SQL join — the same way it
joins related
data across sheets and tables elsewhere in the product. Your
collections don't need to be flattened or combined by hand first.
Running in your own environment
None of this requires moving your data anywhere. tableArth.ai lets you talk to your private databases in natural language — querying external databases such as PostgreSQL, MySQL, MongoDB, and Druid running inside your own private environment, simply by asking. For MongoDB specifically, that means the engine connects to your cluster, reads the collections it's been given access to, and runs the generated query or pipeline in place. Nothing is exported, copied to a third-party warehouse, or handed to a model as a bulk dump.
Execution is read-only and scoped to whatever access that connection already has. And because the answer is grounded in a real pipeline run against your real documents — not a guess dressed up as a sentence — it's verifiable: you can see what ran and check it against the source collection. If a generated query is invalid or fails, tableArth.ai detects that and retries up to three times before it ever surfaces an error, the same retry intelligence that backs its SQL queries. For teams that need finer control over what a model sees while it works, four privacy modes — full AI, masked data, hybrid/stats-only, and a fully local template mode — are configurable per database, workspace, or table; see how the privacy modes work.
Do I need to know the aggregation framework?
No. Ask your question in plain English and tableArth.ai writes the query or aggregation pipeline — $match, $group, $unwind, $lookup, whatever the question needs — runs it, and returns the answer and a chart. You never write a MongoDB operator yourself.
Does my data leave my environment?
No. tableArth.ai queries your MongoDB database running inside your own private environment. The query runs where your data already lives — nothing is exported or copied out to answer a question.
Can it handle nested documents?
Yes. tableArth.ai reads nested sub-documents and arrays as part of your collection's structure, the same way it reads relationships in a relational database. When a question depends on a nested field or an array, it writes the $unwind, $lookup, or nested $project stages automatically.
How accurate is it?
Accuracy comes from being schema-aware and self-correcting. tableArth.ai reads your collections' real field names and types, validates the query it generates, and retries up to three times if a query is invalid before falling back gracefully. Because answers are grounded in a real aggregation pipeline run against your data, results are verifiable rather than guessed.