MongoDB: die Dokumenten-Datenbank zwischen SSPL, Atlas und Voyage-AI-Integration

Was ist MongoDB?

MongoDB ist eine dokumenten-orientierte Datenbank, die seit 2009 entwickelt wird und das wohl bekannteste NoSQL-System darstellt. Statt Tabellen mit Zeilen und Spalten speichert MongoDB Dokumente in BSON-Format (binäres JSON) innerhalb von Collections. Jedes Dokument kann eine andere Struktur haben -- das macht das System für wirklich schemalose Daten attraktiv. Im Mai 2026 ist Version 8.0 stabil, mit verbesserter Query-Performance, neuen Aggregations-Operatoren und Atlas-Integration.

Lizenz-Modell: MongoDB ist seit 2018 unter der Server Side Public License (SSPL) lizenziert -- eine Lizenz, die OSI nicht als Open-Source anerkennt, weil sie das Anbieten der Software als Cloud-Service ohne Quellcode-Veröffentlichung einschränkt. Für interne KMU-Nutzung und SaaS-Produkte, die MongoDB nicht selbst als Service weiterverkaufen, ist die SSPL kein Hindernis. Wer Cloud-Reselling plant, prüft die Lizenz oder geht auf MongoDB Atlas (das offizielle gehostete Angebot).

Im Mai 2026 hat MongoDB Inc. nach der Voyage-AI-Akquisition (Ende 2024) die KI-Integration deutlich ausgebaut: native Embedding-Generierung im Atlas-Cluster, Vector-Search ohne externe Vektor-DB, Reranking-Modelle eingebaut. Damit positioniert sich MongoDB als All-in-One-Datenbank für KI-Anwendungen -- besonders für Teams, die kein separates Qdrant oder Pinecone betreiben möchten.

Atlas Cloud (mongodb.com/atlas) ist als verteilter Managed-Service in 100+ Cloud-Regionen verfügbar, darunter Frankfurt (EU-West-1) und Zürich (UBS-eigenes Cloud-Setup ab 2025). Self-Host läuft als Docker-Container oder direkt als systemd-Service. Free-Tier (M0) auf Atlas bietet 512 MB Storage und 100 Connections für Prototypen, M10 startet bei USD 57 pro Monat für Production.

Warum es wichtig ist

MongoDB ist die häufigste Fehl-Entscheidung in CH-KMU-Projekten 2026. Diese Aussage braucht Nuance -- es gibt klare Fälle, in denen MongoDB die richtige Wahl ist, aber sie ist seltener als der Anteil der MongoDB-Projekte vermuten lässt.

Der Grund: viele Entwickler kennen 2026 nur MongoDB als "die NoSQL-DB" und greifen reflexartig danach, wenn ihre Daten "irgendwie unstrukturiert" sind. In 80 Prozent der Fälle könnten dieselben Anwendungen mit PostgreSQL und einer JSONB-Spalte gebaut werden -- mit identischer Flexibilität plus klassischer SQL-Power, ACID-Transaktionen über mehrere Dokumente, sauberer Lizenz (MIT-ähnlich vs. SSPL) und einfacherem Self-Host. Eine später notwendige Migration von MongoDB auf Postgres ist eine 2-4-Wochen-Übung mit Schema-Redesign.

Wann ist MongoDB die richtige Wahl? Wenn Daten tatsächlich schemalos sind. Beispiele: ein IoT-System mit 50+ Sensor-Typen, jeder mit eigenem Schema. Ein CMS mit nutzerdefinierten Inhaltstypen und unbegrenzten Feldern. Game-State-Speicherung mit dynamisch wechselnden Strukturen. Eine Mobile-App, die Benutzer-generierte Inhalte mit unterschiedlichen Strukturen speichert.

MongoDB Atlas 2026 mit Voyage-AI-Integration ist für KI-RAG-Anwendungen tatsächlich attraktiv -- wer ohnehin auf Atlas hostet und KI-Wissensbasen baut, kann Embedding, Vector-Search und LLM-Aggregation in einer DB erledigen. Das spart Qdrant/Pinecone als zweite Komponente. Aber: die EU-Region-Verfügbarkeit muss klar vereinbart sein (Frankfurt M10+), und AVV mit MongoDB Inc. für Treuhand-Daten ist Pflicht.

Für den CH-Treuhand-Markt empfehlen wir 2026 folgende Heuristik: starte mit PostgreSQL + jsonb. Wenn nach 6 Monaten klar wird, dass die Daten wirklich schemalos sind und JSONB-Queries unpraktisch werden, dann MongoDB als ergänzende DB oder Migration. Reverse-Order (Mongo first, dann auf SQL gewechselt) ist viel teurer.

Wie es funktioniert

MongoDB speichert Daten als BSON-Dokumente innerhalb von Collections. Eine Collection ist analog zu einer SQL-Tabelle, aber ohne Schema-Zwang. Ein Document hat eine eindeutige _id (ObjectId, automatisch generiert), und kann beliebige Felder enthalten -- inklusive verschachtelte Objekte und Arrays.

Ein Beispiel-Setup mit Node-Treiber (Mongoose) oder direkter MongoDB-Driver-API:

// Collection anlegen und einfügen db.mandanten.insertOne({ name: "Müller Treuhand AG", branche: "Steuerberatung", ansprechpartner: [ { name: "Anna Müller", email: "anna@müller.ch", rolle: "CEO" }, { name: "Peter Schmid", email: "peter@müller.ch", rolle: "CFO" } ], metadata: { regnr: "CHE-123.456.789", created: ISODate("2026-05-01") } });

// Query mit Filter und Projection db.mandanten.find( { "ansprechpartner.rolle": "CEO" }, { name: 1, "ansprechpartner.$": 1 } );

Indexe sind klassische B-Tree-Indexes plus spezielle Geo-Indexes, Text-Indexes, und (seit 8.0 verbessert) Vector-Indexes via Voyage-AI. Das Aggregations-Framework ist eine Pipeline-basierte Query-Sprache, die in vielen Fällen SQL ersetzt -- $match, $group, $project, $lookup (Join), $vectorSearch.

Replikation läuft über Replica Sets: ein Primary, ein oder mehrere Secondaries, automatischer Failover. Sharding teilt grosse Collections horizontal auf mehrere Shard-Cluster auf. Beides ist im Atlas-Service vorkonfiguriert; im Self-Host muss man die mongod-Prozesse manuell aufsetzen.

Für KI-Anwendungen seit der Voyage-AI-Akquisition: Vector-Search-Index über Atlas-UI oder Driver konfigurierbar, Embeddings können automatisch generiert werden (model: voyage-3-large, voyage-multimodal), Reranking via voyage-rerank-2.

Backup: in Atlas automatisch (Continuous-Backup mit PITR). Im Self-Host via mongodump (logisch) oder mongodb-snapshot mit fs-Tools (physikalisch). Recovery via mongorestore -- bei 50 GB ca. 30-60 Minuten.

MongoDB in 5 Schritten produktiv

1. 01Entscheidung Atlas vs. Self-Host: bei < 5 Mongo-Apps lohnt Atlas (M10 ab USD 57/Monat); bei mehreren Mongo-Stacks oder Datenresidenz-Pflicht: Self-Host mit Docker plus Replica Set.
2. 02Collections und Indexes planen: pro Use-Case oder pro Mandant eine Collection. Compound-Indexes auf Filter-Felder, Text-Index für Full-Text-Search, ggf. Vector-Index über Voyage AI für KI-Wissensbasen.
3. 03Backup-Strategie: in Atlas Continuous Backup mit PITR aktivieren. Im Self-Host: mongodump-Crons in S3-kompatiblen Speicher, ergänzt durch fs-Snapshots.
4. 04Replikation und Sharding: Replica Set mit Primary + 2 Secondaries für HA, Sharding nur bei > 1 TB pro Collection oder hoher Write-Last (> 10k Ops/s pro Shard).
5. 05Monitoring: Atlas hat eingebautes Performance Advisor, Self-Host braucht Prometheus mit mongodb_exporter. Schlüssel-Metriken: Replication Lag, Connection Count, Working-Set vs RAM.

Wann MongoDB einsetzen

Die richtige Wahl, wenn (a) Daten wirklich schemalos sind und sich häufig in Struktur ändern, (b) bestehende Mongo-Anwendung skaliert wird, oder (c) Atlas mit Voyage-AI als All-in-One-KI-Backend genutzt werden soll.

Konkrete Szenarien: IoT-Telemetrie mit 50+ Sensor-Typen je eigenes Schema, CMS mit nutzerdefinierten Content-Types und unbegrenzten Feldern, Catch-All-Event-Storage für Audit-Logs mit unterschiedlichen Event-Strukturen, Mobile-App-Backend mit Benutzer-generierten Inhalten, Game-State-Persistierung mit dynamischen Schemen, dokumenten-orientierte Datenbanken für Verträge und juristische Texte mit verschachtelten Strukturen.

MongoDB Atlas 2026 mit Voyage-AI-Integration ist attraktiv für KI-RAG-Anwendungen: Embedding-Generierung, Vector-Search und Reranking in einer DB-Plattform. EU-Region Frankfurt verfügbar für DSGVO-konforme Setups. AVV mit MongoDB Inc. erforderlich.

Für Anwendungen mit existing-Mongo-Codebase: Migration auf Postgres lohnt nur bei klaren Engpässen (Lizenz-Themen, fehlende Joins, ACID-Erwartungen). Wenn die Anwendung stabil läuft und das Team Mongo-Erfahrung hat, ist Wechsel um des Wechsels willen nicht sinnvoll.

Wann NICHT

Für ein Greenfield-Projekt im Mai 2026 mit relationalen Daten (Mandanten, Verträge, Rechnungen, Buchungen) ist PostgreSQL die bessere Default-Wahl. Postgres mit jsonb deckt 80 Prozent der Mongo-Anwendungsfälle ab, plus Foreign Keys, ACID-Transaktionen über mehrere Tabellen und SQL-Joins.

Für regulierte Branchen mit strikten Datenresidenz-Anforderungen ohne Cloud-Tolerance ist Self-Host-Mongo eine Option, aber operativ aufwendiger als Self-Host-Postgres. Replica Sets und Sharding sind komplexer als Postgres-Streaming-Replication. Wer keine starke MongoDB-Operations-Erfahrung im Team hat, geht zu Postgres.

Für Anwendungen, die später potenziell auf andere Datenbanken migrieren möchten, ist die Mongo-Lock-in grösser als bei Postgres. Mongo-Aggregation-Pipelines sind nicht in SQL umzusetzen, und das Schema-Migrations-Tooling ist enger.

Für Reports mit komplexen Aggregaten über Millionen Dokumente ist Mongo-Aggregation langsamer als ClickHouse/DuckDB. Wer reporting-heavy Workloads hat, kombiniert Mongo (Operational-Store) mit einer columnar-Analytics-DB.

Für kleine Anwendungen mit < 10k Dokumenten ist Mongo overkill. Eine SQLite-DB tut es auch und vermeidet einen Server-Stack.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. MongoDB 8.0 Release Notes · 2026-05
2. MongoDB Voyage AI integration documentation · 2026-05
3. MongoDB SSPL FAQ · 2026-04
4. MongoDB Atlas pricing and regions · 2026-05