MongoDB in MERN

What MongoDB Is and Where It Fits in MERN

MongoDB 1,815 is a document database. A document is a BSON record — a binary, typed superset of JSON — whose field values may be strings, numbers, dates, binary blobs, arrays, or other documents nested to any depth. There is no CREATE TABLE: a collection appears the first time you write to it, and two documents in one collection need not share a field.

The server is written in C++ and, since 3.2, stores everything through the WiredTiger engine: B-tree files on disk, a snappy-compressed write-ahead journal, a checkpoint every 60 seconds, and an internal cache of 50% of (RAM − 1 GB) or 256 MB, whichever is larger. Clients never speak SQL: they send BSON command documents over a binary wire protocol (OP_MSG since 3.6) on TCP port 27017 and get BSON back.

Where MongoDB sits in a MERN request, and what crosses each boundary
Where MongoDB sits in a MERN request, and what crosses each boundary

The consequence for a MERN application is that data never changes shape. A React 7,897 component holds a plain object; Express 24,430 passes it through; the driver serializes it to BSON; the server stores it. No object-relational mapper turns a nested array into a second table, and the design work moves from normalizing to choosing what to nest (Schema Design).

What MongoDB gives up is equally concrete. There are no foreign keys and no cascading deletes: referential integrity is your problem. Joins exist only in the pipeline's $lookup stage ($lookup). Multi-document transactions work (Transactions and Streams) but need a replica set, which a bare mongod is not.