An interviewer asks: "You are starting a new project. Which database would you choose, SQL or NoSQL?" Someone who has only learned the MERN stack often answers, "NoSQL, because it is new." That answer usually ends the interview, and not because MongoDB is a bad choice. It ends it because "new" is not a reason.
NoSQL is not new
MongoDB's first version shipped in 2009. The relational model is older: E. F. Codd described it in "A Relational Model of Data for Large Shared Data Banks" in June 1970. Even older non-relational systems existed before that; IBM's hierarchical IMS shipped in 1967. And relational databases are still the ones developers use most. In the Stack Overflow Developer Survey 2025, PostgreSQL (55.6%), MySQL (40.5%), SQLite (37.5%) and SQL Server (30.1%) led the list of databases respondents had worked with; MongoDB was at 24%.
Family one: relational
A relational database keeps data in tables of rows and columns. Think of a college office that keeps separate registers for students, fees and courses. Each register holds one kind of fact, and the roll number links them.
- Join. To see one student's fees, the clerk matches the two registers by roll number. In SQL, that matching is a JOIN.
- Transaction. When a fee is paid, the office makes the fee entry and the receipt. Both must happen, or neither. That all-or-nothing rule is a transaction, and relational databases give it to you built in.
Family two: NoSQL
In a document database like MongoDB, everything about one student sits in one file: roll number, name, fees, course. One read gets the whole record, with no join. NoSQL is a family, not one design: besides documents there are key-value stores (DynamoDB), wide-column stores (Cassandra) and graph databases (Neo4j).
MongoDB can join too. Its $lookup stage performs a left outer join to another collection, and it has had multi-document transactions since version 4.0. But MongoDB's own data-modelling guide gives this advice: "data that's accessed together should be stored together." The reason is scale.
Why that advice matters: sharding
When data grows too big for one machine, it is split across several. In the college picture, the student files are spread across three campus offices. That split is called sharding. Now a question that needs data from several files means phoning every office and waiting for the slowest one to reply. MongoDB's docs call these scatter/gather queries and warn they "can be long running operations." Keeping related data in one document avoids that.
How relational databases grow
A relational database usually runs on one server, and that goes a long way:
- Scale up first. A bigger machine with more CPU, memory and faster disks.
- Then read replicas. Read-only copies that answer reads. They spread reads, not writes: every write still goes to the primary.
- Then, if you truly need it, sharding. Citus for PostgreSQL and Vitess for MySQL split a relational database across servers; distributed SQL databases such as CockroachDB, YugabyteDB and Spanner do it by design.
Most applications never need the third step. And when they do, the same cost appears: once related rows sit on different shards, joins and transactions get slower and more complicated, in a relational database just as in MongoDB. That is why Citus tells you to keep related rows on the same shard.
The college office stops matching the real thing here: shards are machines on a network, so the "phone calls" run in parallel and take milliseconds, and databases coordinate with protocols like two-phase commit rather than clerks.
The answer to give
Not new or old. The shape of the data, and how much scale it needs.
In an interview, say it like this: "If the data is connected and needs transactions, I will start with a relational database. If each record is separate and document-like, and it needs very large scale, I will choose NoSQL. Either way, I will pick a shard key that keeps related data together."
Sources: Codd, CACM 13(6), 1970; MongoDB, Our Story; Stack Overflow Developer Survey 2025; MongoDB, Data Modeling; MongoDB, $lookup; MongoDB, Sharding; PostgreSQL, High Availability; Citus, Choosing the distribution column; Vitess.