How to query MongoDB with SQL

#Why the question keeps being asked

MongoDB does not speak SQL, and it never has. Its query language is JSON documents for filters and a pipeline of stages for anything more involved. That is a coherent design, and it is a genuine cost for the large number of developers who already think in SELECT, JOIN and GROUP BY.

So the question — can I just write SQL against MongoDB? — is not laziness. It is asking whether you have to relearn a query language to read data you already understand.

There are three honest answers, and they are good at different things.

#1. Translate the query, then run the translation

A tool takes your SELECT, produces the MongoDB find or aggregation pipeline it corresponds to, and executes that against the database.

SELECT customerId, SUM(total) AS revenue
FROM orders
WHERE status = 'paid'
GROUP BY customerId

becomes an ordinary pipeline:

db.orders.aggregate([
  { $match: { status: "paid" } },
  { $group: { _id: "$customerId", revenue: { $sum: "$total" } } }
])

What it is good at. Nothing sits between you and the database at runtime — the server receives a normal MongoDB command, uses normal indexes, and can be explained with explain() like any other query. You can read the generated pipeline, which means you learn the target language while using the source one.

What it is not. It is not a promise that every SQL feature has a MongoDB counterpart. Window functions, recursive CTEs and full outer joins do not have one, and a tool that pretends otherwise is either doing the work in memory behind your back or answering the wrong question.

This is the approach TableCore takes, and the reason it shows you the generated query rather than hiding it. Which parts of SQL it accepts, and which it refuses rather than approximating, is written down in SQL support.

#2. A SQL layer that sits in front of the database

MongoDB's own BI Connector, and the Atlas SQL interface that succeeded it, present MongoDB collections to a SQL client as if they were relational tables. JDBC and ODBC drivers connect, and tools like Tableau or Power BI treat the result as a warehouse.

What it is good at. Existing SQL tooling works unchanged, which is exactly what you want for analytics and reporting.

What it is not. It is another service to deploy, keep running and secure, and the flattening of documents into tables is a modelling decision made for you. For a developer who wants to look at data during development, it is a large amount of machinery for the problem.

#3. Learn the aggregation pipeline

The unfashionable answer, and often the right one. The pipeline is a small language: $match filters, $group aggregates, $sort orders, $project reshapes, $lookup joins. Once the mapping is in your head, it stops being a translation problem.

What it is good at. No layer, no tool, no translation gap. Array handling and nested documents are genuinely more expressive than the SQL equivalents.

What it is not. It is not free. It costs the days it takes, and it does not help the colleague who has to read your pipeline next month and does not have those days.

#The mapping, in one table

Most of the surface maps cleanly, which is what makes translation practical:

What does not appear in that table is the honest part: window functions, recursive CTEs, INTERSECT and EXCEPT, and correlated subqueries in arbitrary positions.

#Choosing between them

Reporting into an existing BI stack: the SQL layer. Building a career on MongoDB: learn the pipeline. Reading and modifying data during development with SQL you already know, while picking the pipeline up as you go: translate.

If the last one describes you, paste a query into the browser-based SQL to MongoDB converter — it runs entirely in your browser, and shows the pipeline next to the SQL. From there, GROUP BY and JOIN have guides of their own.