SQL Terms vs MongoDB Terms

SQL terms vs MongoDB terms can cause confusion even when two people are discussing the same business data. Most of my work focuses on SQL Server performance through the Comprehensive Database Performance Health Check. One engagement reminded me how useful a shared vocabulary can be.

Why I made this comparison

A stockbroking client used both SQL Server and MongoDB. I worked with their MongoDB expert on a SQL Server performance problem. I would say row or table, while my colleague would say document or collection. We sometimes spent more time translating terms than discussing the problem.

Once we agreed on the vocabulary, the conversation became much easier. Here are the five basic comparisons that helped us.

A small SQL Server and MongoDB glossary

The closest everyday matches are table to collection and row to document. They help people communicate, but they do not define a migration design.

Read from a table or a collection

Suppose a SQL Server database already has a table named dbo.Users. This query requests all its columns and rows:

SELECT * FROM dbo.Users;

In mongosh, with the intended database selected, the corresponding starting point for a collection named Users is:

db.Users.find({})

The empty filter matches every document. find() returns a cursor, so matching all documents does not mean the shell displays or loads the entire collection at once. Neither example asks for a particular order. For an application query, select the needed fields, apply a useful filter and specify a sort when order matters.

The SQL Server SELECT was checked with a small local fixture. The mongosh syntax is verified against MongoDB documentation; it was not executed against a MongoDB instance for this refresh.

Where the word mapping stops

Flexible schema still needs design. MongoDB permits documents with different shapes, and schema validation can require fields or types. Choose a document structure for how the application reads and updates its data.

Relationships need their own decision. MongoDB can represent related data through embedded documents or references. A reference should not be assumed to behave like an enforced SQL Server foreign key. Decide how the application will maintain consistency.

The data model does not settle every capability question. For example, MongoDB supports multi-document transactions in supported deployments. Saying document database does not mean saying no transactions. Check the actual requirements and deployment rather than inferring behavior from a glossary.

Continue with the MongoDB articles

• Getting Started With mongosh: Databases, Collections and Documents
• MongoDB insertOne and insertMany: Adding Documents the Right Way
• MongoDB find: Filters, Projections and Sorting for SQL People
• MongoDB updateOne: $set, $inc and Upserts Without Surprises
• MongoDB deleteMany: The Empty Filter That Deletes Everything
• SQL to MongoDB: Mapping SELECT, WHERE, GROUP BY and JOIN

The main lesson from that engagement was simple: agree on the words first, then ask how each product stores, queries and protects the data.

A glossary is not a migration specification, it is a starting point for a clearer conversation.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.