Documents instead of rows

MongoDB stores documents, which are JSON like objects, grouped into collections. There is no fixed schema: two documents in the same collection can have different fields.

What that changes. Related data can live inside one document rather than spread across several tables. An order with its line items, an address and a status history is one document, retrieved in one operation with no joins.

Where that genuinely suits the problem. Data with a natural document shape and varying fields. Catalogues where products have different attributes. Event and activity logs. Content management. Applications where the shape changes frequently during development. And anything where you almost always read a whole object at once.

Where a relational database is better, and this matters because MongoDB is frequently chosen by default. Data with many relationships queried in many directions. Anything needing guaranteed consistency across several entities. Reporting and analysis, where SQL is far better suited. And anything where the same fact appears in several documents, because keeping duplicated data consistent becomes your job rather than the database's.

The honest position. A great many projects that chose MongoDB would have been simpler with Postgres, and the reason they chose it was flexibility during early development rather than a property of the data. Postgres also stores and indexes JSON, which removes much of that argument.

Choose it because your data is document shaped, not because schemas feel restrictive at the start of a project.