Der ehrliche Standard im Jahr 2026 heißt PostgreSQL. Es kommt mit semistrukturierten Daten gut zurecht — JSONB-Spalten mit GIN-Indizes decken die meisten Anforderungen an ein „flexibles Schema" ab — und eine einzelne, gut abgestimmte Instanz skaliert weiter, als die meisten Teams je benötigen. Die nützliche Frage lautet daher nicht „SQL oder NoSQL?", sondern: „Was genau würde eine Dokumentendatenbank für diesen Workload zum besseren Werkzeug machen?"

Was MongoDB tatsächlich ist

MongoDB speichert JSON-ähnliche Dokumente, intern persistiert als BSON (binäres JSON), das zusätzliche Typen wie Datumsangaben und Binärdaten mitbringt und das Traversieren beschleunigt. Dokumente liegen in Collections, jedes Dokument kann seine eigene Struktur haben, und Schema-Validierung ist verfügbar, aber optional. Die Designeinheit ist das Dokument: Sie modellieren Daten danach, wie sie zusammen gelesen und geschrieben werden — nicht entlang normalisierter Tabellen.

Wann das Dokumentenmodell wirklich passt

  • Aggregatorientierte Daten. Eine Bestellung mit ihren Positionen, der Lieferadresse und dem Zahlungsstatus wird als eine Einheit gelesen und geschrieben. Ein einziger Dokumentenzugriff ersetzt einen Join über fünf Tabellen, und der Code bildet sich natürlich auf die Speicherung ab.
  • Echte Schemavarianz. Produktkataloge, CMS-Inhalte und Event-Payloads, bei denen Datensätze aus legitimen Gründen unterschiedliche Felder haben — nicht bloß ein Schema, das Sie noch nicht entworfen haben.
  • Tief verschachtelte, hierarchische Daten, die sich nur mühsam in Zeilen flachklopfen ließen.
  • Horizontale Schreibskalierung. Das eingebaute Sharding von MongoDB verteilt Daten über Knoten, wenn ein Workload tatsächlich einen einzelnen Primary übersteigt — ein echtes Unterscheidungsmerkmal, das allerdings nur wenige Anwendungen je erreichen.

Transaktionen in MongoDB heute

Räumen wir mit einem Mythos auf: MongoDB unterstützt Multi-Dokument-ACID-Transaktionen seit Version 4.0 (2018) und verteilte Transaktionen über Shards hinweg seit 4.2 (2019). „MongoDB kann keine Transaktionen" ist seit fast einem Jahrzehnt falsch. Der reale Trade-off im Jahr 2026 betrifft die Kosten, nicht die Existenz: Multi-Dokument-Transaktionen sind langsamer als Einzeldokument-Schreibvorgänge, erfordern Retry-Logik und unterliegen Laufzeitlimits. Ein gut entworfenes Dokumentenmodell hält die meisten Operationen innerhalb eines einzelnen Dokuments, das für sich genommen atomar ist. Wenn die Mehrheit Ihrer Schreibvorgänge Multi-Dokument-Transaktionen benötigt, ist das ein starkes Signal, dass Ihre Daten relational sind und PostgreSQL Ihnen besser dienen wird.

Wann PostgreSQL die bessere Wahl ist

  • Ihre Entitäten sind wirklich relational: Many-to-many-Beziehungen, Ad-hoc-Joins, Reporting und Analytik über den gesamten Datenbestand.
  • Sie brauchen starke Constraints — Fremdschlüssel, entitätsübergreifende Eindeutigkeit —, die von der Datenbank statt vom Anwendungscode durchgesetzt werden.
  • Ihr Team und Ihr Tooling leben in SQL: BI-Werkzeuge, ORMs, Migrationen, Jahrzehnte an Betriebswissen.
  • Kosten zählen im großen Maßstab. MongoDB Atlas ist operativ exzellent, aber entsprechend bepreist, wenn Daten und Cluster-Tiers wachsen; PostgreSQL läuft überall gut — vom Container bis zu jedem großen Managed-Cloud-Service.

Eine kurze NoSQL-Taxonomie

MongoDB ist eine von vier großen NoSQL-Familien, und diese sind nicht austauschbar:

  • Key-Value-Stores (Redis und sein Valkey-Fork, DynamoDB): ein opaker Wert, der über einen Schlüssel abgerufen wird. Unschlagbar für Caching, Sessions und einfache Lookups bei extremer Geschwindigkeit — die operativen Details behandeln wir in unserem Redis-Beitrag.
  • Dokumenten-Stores (MongoDB, Couchbase, Firestore): Key-Value, bei dem der Wert ein strukturiertes Dokument ist, das sich über seine Felder indizieren und abfragen lässt.
  • Wide-Column-Stores (Cassandra, HBase, Bigtable): Zeilen mit dynamischen Spalten, partitioniert nach Row Key und optimiert für schnelle Schreibvorgänge und schlüsselbasierte Zugriffe in riesigem Maßstab — denken Sie an Zeitreihen und Telemetrie. Wohlgemerkt sind das keine spaltenorientierten Analytik-Engines wie ClickHouse oder Redshift; Wide-Column-Stores optimieren den Zeilenzugriff innerhalb von Partitionen, nicht vollständige Spaltenscans.
  • Graphdatenbanken (Neo4j, Neptune): Knoten und Kanten für beziehungsorientierte Abfragen — Betrugsringe, Empfehlungen, Abhängigkeitsanalysen —, bei denen die Join-Tiefe ein relationales Modell lahmlegen würde.

Den Trend des Jahres 2026 sollte man ehrlich benennen: Die Branche konvergiert, sie migriert nicht zu NoSQL. PostgreSQL absorbiert über JSONB weiterhin Dokumenten-Workloads, und verteilte SQL-Systeme (CockroachDB, Spanner, Aurora DSQL) bieten inzwischen NoSQL-artige horizontale Skalierung mit SQL-Semantik. NoSQL-Datenbanken sind spezialisierte Werkzeuge, die bei bestimmten Zugriffsmustern gewinnen — kein Nachfolger relationaler Datenbanken.

Die Entscheidung in einem Absatz

Wählen Sie MongoDB, wenn Ihre Daten aggregatförmig sind, Ihr Schema aus echten geschäftlichen Gründen variiert und die Atomarität einzelner Dokumente die meisten Schreibvorgänge abdeckt — und gehen Sie mit dem Wissen hinein, dass Transaktionen existieren, aber mehr kosten, und dass die Atlas-Preise mit Ihrem Erfolg mitwachsen. Wählen Sie PostgreSQL für alles andere, was nach unserer Erfahrung die meisten Systeme sind. Wenn Sie vor der Festlegung auf einen Produktions-Workload eine zweite Meinung wünschen: Unser Cloud-Engineering-Team führt genau diese Art von Datenbankauswahl- und Migrationsbewertungen durch.

Soll das in Produktion laufen? Unser AWS Managed Services-Team betreibt solche Umgebungen rund um die Uhr — Monitoring, Incident Response, Patching und Kostenkontrolle durch namentlich benannte Senior Engineers, ab 3.000 €/Monat.

Tags: #Datenbank #MongoDB #PostgreSQL #NoSQL