MongoDB: the document database between SSPL, Atlas, and Voyage AI integration

What is MongoDB?

MongoDB is a document-oriented database developed since 2009, the best-known NoSQL system. Instead of tables with rows and columns, MongoDB stores documents in BSON format (binary JSON) inside collections. Each document can have a different structure -- which makes the system attractive for truly schemaless data. In May 2026, version 8.0 is stable, with improved query performance, new aggregation operators, and Atlas integration.

License model: MongoDB has been licensed under the Server Side Public License (SSPL) since 2018 -- a license OSI does not recognize as open source because it restricts offering the software as a cloud service without source publication. For internal SME use and SaaS products that do not resell MongoDB itself as a service, SSPL is no obstacle. Anyone planning cloud reselling checks the license or moves to MongoDB Atlas (the official hosted offering).

In May 2026, after the Voyage AI acquisition (end of 2024), MongoDB Inc. significantly expanded its AI integration: native embedding generation in the Atlas cluster, vector search without an external vector DB, built-in reranking models. This positions MongoDB as an all-in-one database for AI applications -- especially for teams that do not want to operate a separate Qdrant or Pinecone.

Atlas Cloud (mongodb.com/atlas) is available as a distributed managed service in 100+ cloud regions, including Frankfurt (EU-West-1) and Zurich (UBS-specific cloud setup since 2025). Self-host runs as a Docker container or directly as a systemd service. Free tier (M0) on Atlas offers 512 MB storage and 100 connections for prototypes, M10 starts at USD 57/month for production.

Why it matters

MongoDB is the most frequent wrong choice in Swiss SME projects in 2026. This statement needs nuance -- there are clear cases where MongoDB is the right choice, but they are rarer than the proportion of MongoDB projects suggests.

The reason: many developers in 2026 know only MongoDB as "the NoSQL DB" and reach for it reflexively when their data is "somehow unstructured". In 80 percent of cases, the same applications could be built with PostgreSQL and a JSONB column -- with identical flexibility plus classic SQL power, ACID transactions across multiple documents, cleaner license (MIT-like vs. SSPL), and simpler self-host. A later necessary migration from MongoDB to Postgres is a 2-4 week task with schema redesign.

When is MongoDB the right choice? When data is truly schemaless. Examples: an IoT system with 50+ sensor types, each with its own schema. A CMS with user-defined content types and unlimited fields. Game-state storage with dynamically changing structures. A mobile app that stores user-generated content with varying structures.

MongoDB Atlas 2026 with Voyage AI integration is genuinely attractive for AI RAG applications -- whoever already hosts on Atlas and builds AI knowledge bases can do embedding, vector search, and LLM aggregation in one DB. That saves Qdrant/Pinecone as a second component. But: EU region availability must be clearly agreed (Frankfurt M10+), and DPA with MongoDB Inc. for fiduciary data is mandatory.

For the Swiss fiduciary market we recommend in 2026 the following heuristic: start with PostgreSQL + jsonb. If after 6 months it becomes clear that the data is truly schemaless and JSONB queries become impractical, then MongoDB as supplementary DB or migration. Reverse order (Mongo first, then switched to SQL) is much more expensive.

How it works

MongoDB stores data as BSON documents inside collections. A collection is analogous to a SQL table but without a schema requirement. A document has a unique _id (ObjectId, auto-generated) and can contain arbitrary fields -- including nested objects and arrays.

A sample setup with the Node driver (Mongoose) or direct MongoDB driver API:

// Insert into a collection db.clients.insertOne({ name: "Müller Treuhand AG", industry: "Tax advisory", contacts: [ { name: "Anna Müller", email: "anna@müller.ch", role: "CEO" }, { name: "Peter Schmid", email: "peter@müller.ch", role: "CFO" } ], metadata: { regNr: "CHE-123.456.789", created: ISODate("2026-05-01") } });

// Query with filter and projection db.clients.find( { "contacts.role": "CEO" }, { name: 1, "contacts.$": 1 } );

Indexes are classic B-tree indexes plus special geo indexes, text indexes, and (improved since 8.0) vector indexes via Voyage AI. The aggregation framework is a pipeline-based query language that replaces SQL in many cases -- $match, $group, $project, $lookup (join), $vectorSearch.

Replication runs via replica sets: one primary, one or more secondaries, automatic failover. Sharding splits large collections horizontally across multiple shard clusters. Both are preconfigured in Atlas; in self-host you must set up the mongod processes manually.

For AI applications since the Voyage AI acquisition: vector search index configurable via Atlas UI or driver, embeddings can be generated automatically (model: voyage-3-large, voyage-multimodal), reranking via voyage-rerank-2.

Backup: in Atlas automatic (continuous backup with PITR). In self-host via mongodump (logical) or mongodb snapshot with fs tools (physical). Recovery via mongorestore -- at 50 GB roughly 30-60 minutes.

MongoDB to production in 5 steps

1. 01Decide Atlas vs. self-host: with < 5 Mongo apps, Atlas pays off (M10 from USD 57/month); with several Mongo stacks or data residency duty: self-host with Docker plus replica set.
2. 02Plan collections and indexes: one collection per use case or per client. Compound indexes on filter fields, text index for full-text search, optionally vector index via Voyage AI for AI knowledge bases.
3. 03Backup strategy: in Atlas enable continuous backup with PITR. In self-host: mongodump cron to S3-compatible storage, supplemented by fs snapshots.
4. 04Replication and sharding: replica set with primary + 2 secondaries for HA, sharding only with > 1 TB per collection or high write load (> 10k ops/s per shard).
5. 05Monitoring: Atlas has built-in Performance Advisor, self-host needs Prometheus with mongodb_exporter. Key metrics: replication lag, connection count, working set vs RAM.

When to use MongoDB

The right choice when (a) data is truly schemaless and frequently changes structure, (b) an existing Mongo application is being scaled, or (c) Atlas with Voyage AI shall be used as an all-in-one AI backend.

Concrete scenarios: IoT telemetry with 50+ sensor types each with its own schema, CMS with user-defined content types and unlimited fields, catch-all event storage for audit logs with varying event structures, mobile app backend with user-generated content, game-state persistence with dynamic schemas, document-oriented databases for contracts and legal texts with nested structures.

MongoDB Atlas 2026 with Voyage AI integration is attractive for AI RAG applications: embedding generation, vector search, and reranking in one DB platform. EU region Frankfurt available for GDPR-compliant setups. DPA with MongoDB Inc. required.

For applications with existing Mongo codebase: migration to Postgres only pays off with clear bottlenecks (license topics, missing joins, ACID expectations). If the application runs stably and the team has Mongo experience, switching for switching sake is not worthwhile.

When not to use

For a greenfield project in May 2026 with relational data (clients, contracts, invoices, bookings), PostgreSQL is the better default. Postgres with jsonb covers 80 percent of Mongo use cases, plus foreign keys, ACID transactions across multiple tables, and SQL joins.

For regulated industries with strict data residency requirements without cloud tolerance, self-host Mongo is an option but operationally heavier than self-host Postgres. Replica sets and sharding are more complex than Postgres streaming replication. Anyone without strong MongoDB operations experience in the team goes to Postgres.

For applications that may later want to migrate to other databases, Mongo lock-in is greater than Postgres. Mongo aggregation pipelines do not translate to SQL, and schema-migration tooling is tighter.

For reports with complex aggregates over millions of documents, Mongo aggregation is slower than ClickHouse/DuckDB. Anyone with reporting-heavy workloads combines Mongo (operational store) with a columnar analytics DB.

For small applications with < 10k documents, Mongo is overkill. A SQLite DB also works and avoids a server stack.

Trade-offs

FAQ

Related topics

Sources

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