b2KIT

SQL to MongoDB Query Converter

Convert SQL SELECT queries to equivalent MongoDB find() syntax with projection and sort support.

Tested tool guide Tested browser tools Checked August 16, 2026

What SQL to MongoDB Query Converter does, with a checked example

SQL thinks in rows and columns; MongoDB returns documents, and this tool rewrites one into the other. Give it a SELECT with a WHERE clause, a column list, ORDER BY, and LIMIT, and it returns the equivalent db.collection.find() call: a filter document, a projection, and a sort chain ready to run in the mongo shell or any driver. The surprise users hit first: find() adds the _id field to every document unless the projection suppresses it, so a faithful conversion emits _id: 0 to match the SQL column list.

Worked example

A concrete input and expected output from the current implementation.

Input

SELECT name, age FROM users WHERE age > 30 ORDER BY age DESC LIMIT 10

Expected output

db.users.find(
  { age: { $gt: 30 } },
  { name: 1, age: 1, _id: 0 }
).sort({ age: -1 }).limit(10)

Each SQL clause maps to one MongoDB construct: WHERE becomes the filter document with $gt for the comparison, the column list becomes the projection with _id: 0 so the output has exactly the requested fields, ORDER BY becomes a sort object using -1 for DESC, and LIMIT becomes a limit call.

How the result is produced

1

WHERE becomes a filter document

SQL comparison operators map onto MongoDB query operators: = becomes a plain field/value pair, > and < become $gt and $lt, IN becomes $in, and LIKE 'x%' becomes an anchored regular expression. AND conditions merge into one filter object, while OR becomes a $or array. Comparisons on the same field combine into a single operator object such as { age: { $gt: 30, $lt: 50 } }.

2

SELECT, ORDER BY, and LIMIT map to the find call

The column list becomes a projection of 1-valued fields, with _id: 0 emitted so returned documents match the SQL column list. ORDER BY becomes a .sort() call with 1 for ASC and -1 for DESC, LIMIT becomes .limit(), and OFFSET becomes .skip(). Operations with no find() equivalent - COUNT, SUM, GROUP BY, JOIN - belong to countDocuments() or the aggregation pipeline, so they cannot become a find() call.

Good uses

  • Porting a SQL report or dashboard query to MongoDB and needing the filter, projection, and sort chain written correctly on the first try.
  • Verifying a hand-written MongoDB query against the SQL it came from, especially operator mappings such as $gt, $in, and regex for LIKE.
  • Learning the field-to-operator correspondence by example, including the pieces SQL has no word for, such as projections and _id handling.

Limits and checks

  • Projection decides _id: MongoDB includes _id in every result unless the projection sets _id: 0. If the emitted projection lacks it, each document carries a field the SQL never returned.
  • Null is not equality: WHERE col IS NULL maps to { col: null }, but that filter also matches documents where col is absent entirely. Isolating null-but-present values needs an additional $exists: true condition.
  • LIKE is an approximation: % becomes .* and _ becomes . in a regular expression, and both SQL equality and MongoDB regex are case-sensitive by default. SQL collations, ESCAPE clauses, and index use of a leading wildcard do not transfer - LIKE '%x' scans the collection in both systems.

Common questions

Does it convert JOINs?

No. find() has no join; MongoDB's closest equivalent is $lookup in the aggregation pipeline, and it produces a different shape - nested arrays rather than flat rows. A SELECT with a JOIN therefore has no find() translation, so the conversion stops at the FROM clause. Rework the join as embedded documents or a hand-written $lookup instead.

Is the output runnable in the mongo shell as-is?

For find()-shaped queries, yes: the filter object, projection, and sort and limit calls are standard MongoDB syntax. Two caveats: collection and field names are copied verbatim from the SQL, so they must match your schema, and SQL literals such as quoted numbers or date strings may need converting to native types like ISODate before the query behaves as intended.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools