MongoDB

Kurz: Eine dokumentenorientierte NoSQL-Datenbank — speichert Daten als flexible JSON-ähnliche Dokumente statt in starren Tabellen mit festen Spalten.

Genauer: Anders als relationale Datenbanken (SQL) erzwingt MongoDB kein festes Schema — jedes Dokument in einer Collection kann theoretisch andere Felder haben. Das eignet sich gut für sich häufig ändernde oder unstrukturierte Daten, erkauft sich das aber mit weniger eingebauten Konsistenzgarantien als klassisches SQL.

Im Detail

{
  "_id": "6512a...",
  "name": "Max Mustermann",
  "bestellungen": [
    { "produkt": "T-Shirt", "menge": 2 },
    { "produkt": "Tasse", "menge": 1 }
  ]
}

Ein “Dokument” in MongoDB ist im Kern ein JSON-ähnliches Objekt (intern binär als BSON gespeichert), das verschachtelte Strukturen direkt enthalten kann — im Beispiel liegen die Bestellungen eines Kunden direkt im selben Dokument, statt wie bei SQL in einer separaten, über einen Fremdschlüssel verknüpften Tabelle. Das kann Abfragen vereinfachen und beschleunigen (alle Daten eines Kunden mit einem einzigen Zugriff), erschwert aber Konsistenz, wenn dieselbe Information an mehreren Stellen dupliziert vorkommt.

MongoDB eignet sich besonders gut, wenn sich die Datenstruktur häufig ändert oder von Dokument zu Dokument stark variiert (z. B. Produktkataloge mit sehr unterschiedlichen Attributen je Kategorie) — für stark vernetzte, konsistenzkritische Daten (z. B. Finanztransaktionen mit strikten Constraints) sind relationale Datenbanken wie PostgreSQL meist die robustere Wahl.

Skalierung und Verteilung

MongoDB wurde von Anfang an mit horizontaler Skalierung im Blick entworfen: Über “Sharding” lassen sich große Collections über mehrere Server verteilen, jeder Server (Shard) verwaltet nur einen Teilbereich der Daten (z. B. nach Kundenregion aufgeteilt). Zusätzlich unterstützt MongoDB “Replica Sets” — mehrere Kopien derselben Daten auf unterschiedlichen Servern für Ausfallsicherheit und Lastverteilung von Lesezugriffen. Relationale Datenbanken können das mittlerweile auch, aber MongoDB hat diesen Anwendungsfall von Beginn an als Kernfeature positioniert, während klassisches SQL-Sharding historisch komplizierter nachgerüstet werden musste.

Konsistenzmodell

Ein wichtiger konzeptioneller Unterschied zu klassischen relationalen Datenbanken: MongoDB garantiert ACID-Transaktionen (Atomicity, Consistency, Isolation, Durability) erst seit Version 4.0 (2018) über mehrere Dokumente hinweg vollständig — davor waren nur Operationen auf einem einzelnen Dokument garantiert atomar. Das spiegelt die grundlegende Philosophie wider: MongoDB priorisiert historisch Flexibilität und Geschwindigkeit über strikte relationale Konsistenzgarantien, während PostgreSQL von Grund auf für strenge Konsistenz nach dem ACID-Prinzip gebaut wurde.

Typische Einsatzgebiete

MongoDB wird häufig für Content-Management-Systeme, Kataloge mit variablen Produktattributen, Logging/Event-Daten und Prototyping eingesetzt, wo sich das Datenmodell noch häufig ändert und ein starres SQL-Schema die Entwicklung eher bremsen würde. Für Anwendungen mit klaren, stabilen Beziehungen zwischen Entitäten (Bestellungen, Nutzer, Zahlungen mit strikten Fremdschlüssel-Constraints) bevorzugen die meisten Teams weiterhin relationale Datenbanken — moderne Ansätze wie Drizzle ORM mit PostgreSQL bieten dabei ähnliche Entwicklungsgeschwindigkeit wie MongoDB, ohne auf relationale Integrität zu verzichten.

Siehe auch: SQL, PostgreSQL, JSON