Ein Produkt im Webshop hat einen Namen, einen Preis und ein Bild. Ein T-Shirt hat zusätzlich Größen und Farben, ein Akkuschrauber eine Spannung und eine Akkukapazität, ein E-Book weder das eine noch das andere. In einer klassischen relationalen Datenbank führt diese Vielfalt schnell zu Tabellen mit Dutzenden leerer Spalten oder zu verschachtelten Hilfstabellen. MongoDB geht einen anderen Weg: Jedes Produkt ist ein eigenes Dokument, das genau die Felder enthält, die es braucht.

Diese Idee hat MongoDB zu einer der meistgenutzten Datenbanken für Web- und App-Entwicklung gemacht. Die erste Wahl für jedes Projekt ist sie trotzdem nicht. Wer MongoDB sinnvoll einsetzen will, sollte verstehen, wie das Dokumentenmodell funktioniert, wie die Datenbank skaliert und wo relationale Systeme nach wie vor die bessere Antwort sind.

Woher MongoDB kommt

Die Gründer von MongoDB, darunter Dwight Merriman und Eliot Horowitz, kamen aus dem Umfeld des Werbenetzwerks DoubleClick. Dort hatten sie erlebt, wie schwer sich relationale Datenbanken mit sehr hohen Zugriffszahlen und häufig wechselnden Datenstrukturen tun. 2007 gründeten sie das Unternehmen 10gen, aus dem später MongoDB Inc. wurde. Die Datenbank erschien 2009 als Open-Source-Projekt; der Name leitet sich von „humongous“ ab, englisch für „riesig“.

MongoDB gehört zur Familie der NoSQL-Datenbanken, also der Systeme, die nicht auf das klassische Tabellenmodell mit SQL setzen. Einen Überblick über die verschiedenen Bauarten – Dokumente, Schlüssel-Wert-Speicher, Spaltenfamilien und Graphen – gibt der Beitrag NoSQL-Datenbanken: Flexibilität und Skalierbarkeit für moderne Anwendungen.

Wie MongoDB Daten speichert

Dokumente statt Zeilen

Die Grundeinheit in MongoDB ist das Dokument. Es sieht aus wie ein JSON-Objekt, wird intern aber als BSON gespeichert, einem binären Format, das zusätzliche Datentypen wie Datumswerte, Dezimalzahlen oder Binärdaten kennt. Jedes Dokument erhält ein eindeutiges Feld _id, das MongoDB automatisch vergibt, wenn die Anwendung keines mitliefert.

Ein Dokument kann verschachtelte Objekte und Listen enthalten. Eine Bestellung im Webshop lässt sich so samt Lieferadresse und Positionen in einem einzigen Dokument ablegen:

// Eine Bestellung mit eingebetteten Positionen in der Collection "bestellungen"
db.bestellungen.insertOne({
  kunde: 'K-10423',
  datum: new Date('2026-10-28'),
  lieferadresse: { strasse: 'Domstraße 1', plz: '50668', ort: 'Köln' },
  positionen: [
    { artikel: 'T-Shirt', groesse: 'M', farbe: 'blau', menge: 2, preis: 19.9 },
    { artikel: 'Akkuschrauber', spannung: '18 V', menge: 1, preis: 129.0 },
  ],
  status: 'offen',
});

In einer relationalen Datenbank wären dafür mindestens drei Tabellen nötig: Bestellungen, Positionen und Adressen. Beim Lesen müsste die Datenbank sie per Join wieder zusammenführen. MongoDB liefert die Bestellung mit einem einzigen Zugriff aus. Das ist der Kern des Leistungsvorteils, den Entwicklerteams an MongoDB schätzen.

Collections und flexibles Schema

Dokumente liegen in Collections, vergleichbar mit Tabellen. Anders als eine Tabelle schreibt eine Collection aber standardmäßig nicht vor, welche Felder ein Dokument haben muss. Kommt ein neues Attribut hinzu, etwa ein Nachhaltigkeitslabel für einige Produkte, speichert die Anwendung es einfach mit. Eine Migration der gesamten Tabelle entfällt.

Diese Freiheit hat eine Kehrseite. Wenn jede Anwendung schreiben kann, was sie will, stehen nach einigen Jahren drei Schreibweisen für dasselbe Feld in der Datenbank. MongoDB bietet deshalb eine Schemavalidierung per JSON Schema an, mit der sich Pflichtfelder und Datentypen je Collection festlegen lassen. Unsere Empfehlung: Nutzen Sie sie für alle Collections, die mehr als ein Team oder ein Dienst beschreibt. „Schemalos“ heißt in der Praxis nur, dass das Schema in der Anwendung statt in der Datenbank steckt.

Abfragen, Indizes und Aggregation

Gelesen und geschrieben wird über die MongoDB Query API, die in den offiziellen Treibern für Sprachen wie JavaScript, Python, Java, C# oder Go zur Verfügung steht. Eine einfache Abfrage sucht Dokumente anhand von Feldwerten, auch in verschachtelten Objekten und Listen:

// Alle offenen Bestellungen mit mindestens einem Akkuschrauber
db.bestellungen.find({ status: 'offen', 'positionen.artikel': 'Akkuschrauber' });

Damit solche Abfragen bei Millionen Dokumenten schnell bleiben, braucht es Indizes – sortierte Verzeichnisse über einzelne Felder oder Feldkombinationen, ähnlich dem Register eines Fachbuchs. MongoDB unterstützt neben einfachen und zusammengesetzten Indizes unter anderem Indizes auf Listenfelder, Geodaten und Textfelder sowie Indizes mit Ablaufzeit, die etwa Sitzungsdaten nach einer bestimmten Frist automatisch löschen.

Für Auswertungen gibt es die Aggregation Pipeline. Dabei durchlaufen die Dokumente mehrere Stufen nacheinander: filtern, gruppieren, sortieren, umformen. So lässt sich etwa der Umsatz je Artikel im letzten Monat direkt in der Datenbank berechnen:

// Umsatz je Artikel aus allen Bestellungen seit dem 1. Oktober 2026
db.bestellungen.aggregate([
  { $match: { datum: { $gte: new Date('2026-10-01') } } },
  { $unwind: '$positionen' },
  {
    $group: {
      _id: '$positionen.artikel',
      umsatz: { $sum: { $multiply: ['$positionen.menge', '$positionen.preis'] } },
    },
  },
  { $sort: { umsatz: -1 } },
]);

Die Pipeline kann über die Stufe $lookup auch Daten aus anderen Collections hinzuziehen. Wer das aber ständig braucht, hat oft ein Datenmodell, das eigentlich relational ist.

Skalierung: Replica Sets und Sharding

Den Ruf als skalierbare Datenbank verdankt MongoDB zwei Mechanismen.

Replica Sets sorgen für Ausfallsicherheit. Eine Datenbank läuft dabei auf mehreren Servern, üblicherweise drei. Ein Server nimmt Schreibzugriffe an, die anderen halten Kopien. Fällt der primäre Server aus, wählen die übrigen automatisch einen neuen. Für einen Webshop heißt das: Ein defekter Server legt den Bestellprozess nicht lahm, sondern verursacht im besten Fall nur eine kurze Unterbrechung von Sekunden.

Sharding verteilt die Daten auf mehrere Replica Sets. Anhand eines Shard-Schlüssels, etwa der Kundennummer, entscheidet MongoDB, auf welchem Teilcluster ein Dokument liegt. Kommen mehr Daten oder Zugriffe hinzu, ergänzt man weitere Shards, statt einen einzelnen Server immer größer zu kaufen. Diese horizontale Skalierung war von Anfang an Teil des Designs.

Der Shard-Schlüssel ist allerdings die folgenreichste Entscheidung im ganzen Projekt. Ist er schlecht gewählt, landen die meisten Zugriffe auf einem einzigen Shard, und der Cluster skaliert nicht. Neuere Versionen erlauben zwar, den Schlüssel nachträglich zu ändern, das bleibt aber ein aufwendiger Vorgang. Für die meisten mittelständischen Anwendungen reicht ohnehin ein einzelnes Replica Set; Sharding wird erst bei sehr großen Datenmengen oder Schreiblasten nötig. Wie das für einen wachsenden Onlineshop konkret aussieht, beschreibt der Infothek-Artikel MongoDB-Skalierbarkeit für Online-Shops.

Transaktionen, Konsistenz und Sicherheit

Ein verbreitetes Vorurteil lautet, MongoDB sei für Geschäftsdaten zu unzuverlässig. Das stimmte in den Anfangsjahren teilweise, ist aber überholt. Änderungen an einem einzelnen Dokument sind in MongoDB immer atomar, also ganz oder gar nicht. Seit Version 4.0 aus dem Jahr 2018 unterstützt MongoDB zudem Transaktionen über mehrere Dokumente mit ACID-Eigenschaften, seit Version 4.2 auch über Shards hinweg.

Trotzdem gilt: Wer ständig Transaktionen über viele Collections braucht, etwa in der Buchhaltung, arbeitet gegen das Dokumentenmodell. Dort spielen relationale Datenbanken wie PostgreSQL ihre Stärken aus.

Bei der Sicherheit bringt MongoDB das Übliche mit: Authentifizierung, rollenbasierte Rechte, verschlüsselte Verbindungen und Verschlüsselung der gespeicherten Daten. Hinzu kommt Queryable Encryption, mit der sich verschlüsselte Felder durchsuchen lassen, ohne dass der Datenbankserver die Klartexte sieht. Viele bekannt gewordene Datenlecks rund um MongoDB gingen in der Vergangenheit auf schlecht konfigurierte Server zurück, die ohne Passwort aus dem Internet erreichbar waren – ein Betriebsfehler, kein Produktfehler. Für personenbezogene Daten nach DSGVO zählt am Ende die Konfiguration: Zugriffskontrolle, Verschlüsselung, Standort der Server und ein Vertrag zur Auftragsverarbeitung, wenn ein Cloud-Dienst im Spiel ist.

Lizenz und Betrieb: Community, Enterprise und Atlas

MongoDB ist seit 2018 nicht mehr im klassischen Sinne Open Source. Damals wechselte der Hersteller für neue Versionen von der AGPL zur Server Side Public License (SSPL). Für Unternehmen, die MongoDB in ihrer eigenen Anwendung nutzen, ändert das in der Regel nichts. Die SSPL zielt auf Anbieter, die MongoDB selbst als Clouddienst verkaufen wollen: Sie müssten dann den Quellcode ihrer gesamten Betriebsplattform offenlegen. Die Open Source Initiative erkennt die SSPL nicht als Open-Source-Lizenz an, weshalb manche Linux-Distributionen MongoDB nicht mehr mitliefern. Wer Lizenzfragen für ein konkretes Produkt klären muss, sollte das mit der Rechtsabteilung tun.

Für den Betrieb gibt es drei Wege:

• Community Edition: kostenlos, selbst betrieben auf eigenen Servern oder in Containern.
• Enterprise Advanced: kostenpflichtige Ausgabe mit Zusatzfunktionen etwa für Verzeichnisdienste, Auditing und Verwaltungswerkzeuge sowie mit Herstellersupport.
• MongoDB Atlas: der Clouddienst des Herstellers, der auf AWS, Microsoft Azure und Google Cloud läuft. Atlas übernimmt Updates, Backups und Skalierung; Rechenzentren in Deutschland stehen zur Auswahl. Ein kostenloser Einstiegscluster eignet sich zum Ausprobieren, nicht für den Produktivbetrieb.

Atlas bündelt inzwischen mehr als nur die Datenbank. MongoDB Search (früher Atlas Search) bringt eine Volltextsuche auf Basis von Apache Lucene mit, MongoDB Vector Search (früher Atlas Vector Search) speichert und durchsucht Vektoren, wie sie KI-Anwendungen für semantische Suche oder Retrieval Augmented Generation brauchen. Seit Mitte 2026 stehen beide auch für die selbst betriebene Community Edition zur Verfügung. Das kann eine separate Suchmaschine überflüssig machen, bindet ein Projekt aber stärker an den Hersteller.

Nicht jedes frühere Angebot hat überlebt. Die Synchronisationslösung Realm, die MongoDB 2019 übernahm und später als Atlas Device Sync vermarktete, hat der Hersteller 2024 abgekündigt und Ende September 2025 eingestellt. Auch die Serverless-Variante von Atlas gibt es nicht mehr; bestehende Instanzen wurden auf andere Cluster-Typen umgezogen. Wer Apps mit Offline-Synchronisation plant, sollte heute auf andere Lösungen setzen.

Wann MongoDB passt – und wann nicht

MongoDB spielt seine Stärken aus, wenn Datensätze unterschiedlich aufgebaut sind, häufig als Ganzes gelesen werden und sich das Datenmodell im Lauf des Projekts noch ändert. Typische Beispiele:

• Produktkataloge mit sehr unterschiedlichen Attributen,
• Inhalte und Profile in Content-Management-Systemen und Apps,
• Ereignis- und Sensordaten, für die MongoDB eigene Zeitreihen-Collections anbietet,
• Backends für Web- und Mobilanwendungen, bei denen die Daten ohnehin als JSON durch die Schnittstellen laufen.

Weniger geeignet ist MongoDB für stark vernetzte Daten mit vielen Querbezügen, für komplexe Ad-hoc-Auswertungen über viele Entitäten und für Anwendungen, in denen Konsistenz über viele Datensätze hinweg das Hauptthema ist, etwa Warenwirtschaft oder Finanzbuchhaltung. Wer zwischen den Welten abwägt, findet im Beitrag Datenbanken verstehen: Von SQL bis NoSQL eine Gegenüberstellung.

Ein Wechsel von einer relationalen Datenbank ist möglich, aber kein reiner Export und Import. Das Datenmodell muss neu gedacht werden: Was wird eingebettet, was referenziert? Der Infothek-Artikel Von MySQL zu MongoDB beschreibt die Schritte im Einzelnen.

Was das für Ihr Team bedeutet

MongoDB ist ausgereift, gut dokumentiert und in fast allen Programmiersprachen bequem anzusprechen. Für Anwendungen mit wechselnden, dokumentartigen Daten ist sie eine solide Wahl, und die Einstiegshürde ist niedrig. Überschätzt wird dagegen oft der Skalierungsvorteil: Die meisten Anwendungen erreichen nie eine Größe, bei der eine gut eingerichtete relationale Datenbank an Grenzen stößt. Unterschätzt wird die Arbeit am Datenmodell. Weil MongoDB anfangs wenig erzwingt, rächen sich unklare Strukturen erst später.

Unsere Einschätzung: Entscheiden Sie nach dem Zugriffsmuster Ihrer Daten, nicht nach dem Ruf der Technologie. Wenn Ihre Anwendung überwiegend ganze Objekte liest und schreibt, ist MongoDB eine gute Option. Wenn sie vor allem Beziehungen auswertet und verknüpft, ist ein relationales System meist die bessere Grundlage. Und klären Sie früh, ob Sie selbst betreiben oder Atlas nutzen wollen – das beeinflusst Kosten, Datenschutz und Herstellerbindung mehr als jede technische Detailfrage.

Wenn Sie ein Datenmodell für MongoDB entwerfen, eine bestehende Installation prüfen lassen oder Ihr Team schulen möchten, finden Sie auf unserer Themenseite MongoDB – Beratung, Coaching, Seminare und Support die passenden Angebote.

Häufige Fragen zu MongoDB

Ist MongoDB kostenlos?

Die Community Edition ist kostenlos nutzbar, auch kommerziell, solange Sie MongoDB nicht selbst als Datenbankdienst an Dritte anbieten. Kosten entstehen für Enterprise Advanced, für Herstellersupport und für Atlas-Cluster oberhalb des kostenlosen Einstiegsangebots.

Ist MongoDB nur etwas für große Datenmengen?

Nein. Viele Projekte nutzen MongoDB wegen des flexiblen Datenmodells und der einfachen Anbindung an JavaScript- und Node.js-Anwendungen, nicht wegen der Datenmenge. Wie sich MongoDB mit Node.js und Express verbinden lässt, zeigt der Beitrag zur Integration von Express und MongoDB.

Gibt es Alternativen, die MongoDB-kompatibel sind?

Einige Clouddienste bieten Schnittstellen an, die zur MongoDB-API kompatibel sind, etwa Amazon DocumentDB und Azure Cosmos DB. Die Kompatibilität ist jedoch nicht vollständig: Einzelne Befehle, Operatoren oder Versionsstände fehlen. Prüfen Sie vor einem Wechsel, ob Ihre Anwendung genau die Funktionen nutzt, die der Dienst unterstützt.