MongoDB

In short: A document-oriented NoSQL database — stores data as flexible JSON-like documents instead of in rigid tables with fixed columns.

In more detail: Unlike relational databases (SQL), MongoDB doesn’t enforce a fixed schema — every document in a collection can, in theory, have different fields. This suits frequently changing or unstructured data well, but at the cost of fewer built-in consistency guarantees than classic SQL.

In Depth

{
  "_id": "6512a...",
  "name": "Max Mustermann",
  "orders": [
    { "product": "T-Shirt", "quantity": 2 },
    { "product": "Mug", "quantity": 1 }
  ]
}

A “document” in MongoDB is, at its core, a JSON-like object (internally stored in binary as BSON) that can directly contain nested structures — in the example, a customer’s orders sit directly in the same document, instead of in a separate table linked via a foreign key as with SQL. This can simplify and speed up queries (all of a customer’s data with a single access), but complicates consistency when the same information is duplicated in several places.

MongoDB is especially well suited when the data structure changes frequently, or varies strongly from document to document (e.g. product catalogues with very different attributes per category) — for strongly interconnected, consistency-critical data (e.g. financial transactions with strict constraints), relational databases like PostgreSQL are usually the more robust choice.

Scaling and distribution

MongoDB was designed with horizontal scaling in mind from the start: via “sharding”, large collections can be spread across several servers, with each server (shard) managing only a portion of the data (e.g. split by customer region). MongoDB also supports “replica sets” — several copies of the same data on different servers, for fault tolerance and load balancing of read access. Relational databases can now do this too, but MongoDB positioned this use case as a core feature from the start, while classic SQL sharding historically had to be retrofitted in a more complicated way.

Consistency model

An important conceptual difference from classic relational databases: MongoDB has only fully guaranteed ACID transactions (Atomicity, Consistency, Isolation, Durability) across multiple documents since version 4.0 (2018) — before that, only operations on a single document were guaranteed atomic. This reflects the underlying philosophy: MongoDB has historically prioritised flexibility and speed over strict relational consistency guarantees, while PostgreSQL was built from the ground up for strict consistency following the ACID principle.

Typical use cases

MongoDB is frequently used for content management systems, catalogues with variable product attributes, logging/event data, and prototyping, where the data model still changes frequently and a rigid SQL schema would tend to slow down development. For applications with clear, stable relationships between entities (orders, users, payments with strict foreign-key constraints), most teams still prefer relational databases — modern approaches like Drizzle ORM with PostgreSQL offer similar development speed to MongoDB, without giving up relational integrity.

See also: SQL, PostgreSQL, JSON