NoSQL & Document Databases

A document database stores each record as a self-contained document — usually JSON — instead of a row in a fixed table. Fields, nested objects and arrays live together, so what an app reads in one go is also stored in one place. MongoDB is the best-known example.

Where you meet it

MongoDB — the classic document store, JSON in, JSON out.
DynamoDB (AWS) — a managed key-value/document store behind a lot of apps at scale.
User profiles, product catalogs, event logs, CMS content — anything whose shape varies from record to record.

What it does

It drops the fixed table grid. Each document carries its own fields, and two documents in the same collection need not look alike. Related data is embedded inside the document rather than spread across tables, so a single read returns the whole object — no JOIN to reassemble it.

"Schemaless" just moves the schema into your code — and every embedded copy you read fast is a copy you now have to update.

How it works

Documents are self-describing field-and-value pairs, grouped into collections. Values can nest: objects inside objects, arrays of values. MongoDB stores them as BSON (binary JSON) and gives each document a unique _id. You query by field, not by table position.

// collection: users — one self-contained document
{
  "_id": "u_1",
  "name": "Ana",
  "age": 34,
  "address": { "city": "Berlin" },   // nested object
  "orders": [                          // embedded array, no JOIN
    { "item": "Pen",  "qty": 2 },
    { "item": "Book", "qty": 1 }
  ]
}

// query by field
db.users.find({ "address.city": "Berlin" })

Because each document is independent, the data spreads cleanly across machines — the store can scale horizontally (sharding) instead of buying one bigger server. The price of embedding is denormalization: the same data may be copied into several documents.

Watch out

"Schemaless" doesn't mean no schema. The schema just moves out of the database and into your application code — which now has to enforce it.
Denormalization duplicates data. Embed a user's name in 1,000 orders and a name change means 1,000 updates — that's the consistency cost you trade for fast reads.
Joins aren't the default, and transactions were once single-document only. MongoDB has $lookup (a left-outer join in its aggregation pipeline) and now supports multi-document ACID transactions, but the docs still steer you toward good embedding first; DynamoDB has no JOIN by design.
NoSQL isn't automatically "better than SQL". It's a different trade-off. Heavy joins, multi-row transactions and strong consistency still favour relational — many real systems use both.

Go deeper

Eine Dokument-Datenbank speichert jeden Datensatz als eigenständiges Dokument — meist JSON — statt als Zeile in einer festen Tabelle. Felder, verschachtelte Objekte und Arrays liegen zusammen: Was die App in einem Rutsch liest, steht auch an einem Ort. MongoDB ist das bekannteste Beispiel.

Wo es vorkommt

MongoDB — der klassische Document Store, JSON rein, JSON raus.
DynamoDB (AWS) — ein managed Key-Value-/Dokument-Store hinter vielen Apps im großen Maßstab.
User-Profile, Produktkataloge, Event-Logs, CMS-Inhalte — alles, dessen Form von Datensatz zu Datensatz variiert.

Was es tut

Es lässt das feste Tabellenraster weg. Jedes Dokument trägt seine eigenen Felder, und zwei Dokumente derselben Collection müssen nicht gleich aussehen. Verwandte Daten werden ins Dokument eingebettet statt über Tabellen verteilt — ein einziger Lesezugriff liefert das ganze Objekt, ohne JOIN zum Zusammensetzen.

"Schemalos" verschiebt das Schema nur in deinen Code — und jede eingebettete Kopie, die du schnell liest, musst du jetzt auch pflegen.

Wie es funktioniert

Dokumente sind selbstbeschreibende Feld-Wert-Paare, gruppiert in Collections. Werte können verschachteln: Objekte in Objekten, Arrays von Werten. MongoDB speichert sie als BSON (binäres JSON) und gibt jedem Dokument eine eindeutige _id. Abgefragt wird nach Feld, nicht nach Tabellenposition.

// collection: users — ein eigenständiges Dokument
{
  "_id": "u_1",
  "name": "Ana",
  "age": 34,
  "address": { "city": "Berlin" },   // verschachteltes Objekt
  "orders": [                          // eingebettetes Array, kein JOIN
    { "item": "Pen",  "qty": 2 },
    { "item": "Book", "qty": 1 }
  ]
}

// Abfrage nach Feld
db.users.find({ "address.city": "Berlin" })

Weil jedes Dokument unabhängig ist, verteilen sich die Daten sauber über Maschinen — der Store kann horizontal skalieren (Sharding), statt einen größeren Server zu kaufen. Der Preis des Einbettens ist Denormalisierung: Dieselben Daten liegen womöglich in mehreren Dokumenten kopiert.

Worauf achten

"Schemalos" heißt nicht ohne Schema. Das Schema wandert nur aus der Datenbank in deinen App-Code — der es jetzt erzwingen muss.
Denormalisierung dupliziert Daten. Bettest du den Namen eines Users in 1.000 Orders ein, kostet eine Namensänderung 1.000 Updates — das ist der Konsistenz-Preis für schnelle Reads.
JOINs sind nicht der Normalfall, und Transaktionen waren früher nur pro Dokument. MongoDB hat $lookup (einen Left-Outer-Join in der Aggregation) und unterstützt heute Multi-Dokument-ACID-Transaktionen, lenkt in der Doku aber weiter zuerst auf gutes Einbetten; DynamoDB hat per Design keinen JOIN.
NoSQL ist nicht automatisch "besser als SQL". Es ist ein anderer Trade-off. Viele Joins, Transaktionen über Zeilen und starke Konsistenz sprechen weiter für Relational — viele echte Systeme nutzen beides.