Unit 5.4: NoSQL Databases (Managed MongoDB)

Introduction

The relational cluster from Unit 5.3 anchors FinCorp's systems of record: account balances, ledgers, and transactions where a fixed schema and strong consistency are the point. But not every FinCorp workload wants a fixed schema. The fraud-scoring service ingests heterogeneous event documents whose fields differ by channel and evolve every sprint, and the customer-360 service stitches together nested profile, consent, and interaction data that would otherwise sprawl across a dozen joined tables. These are document workloads, and on IONOS they land on Managed MongoDB.

This unit opens at the model decision (when document beats relational) and the edition decision (which is permanent in a way that matters), then builds a cluster in the Data Center Designer and connects to it. Two IONOS boundaries shape every design choice here, so we state them plainly and design around them: Managed MongoDB has no managed change-stream replication to a second cluster, and the Acronis-based Backup Service does not back up managed databases at all.

1. The Document Model and When It Fits Over Relational

MongoDB stores data as BSON documents grouped into collections, with no enforced table schema. That is the whole reason to reach for it. A document workload fits when the records are self-contained aggregates whose shape varies or evolves, when most reads pull one rich nested object rather than joining many normalized rows, and when the schema must change without a coordinated migration. The relational tier remains the right answer when you need multi-row ACID transactions across normalized tables, referential integrity enforced by the engine, or ad-hoc SQL analytics on a stable schema. For FinCorp, the ledger stays on Managed PostgreSQL; the fraud-event store and the customer-360 aggregate move to Managed MongoDB because their documents are irregular and their schema turns over constantly.

The IONOS Database Manager supports MongoDB versions 6.0 and 7.0, fully managed (provisioning, patching, updates, and monitoring are handled by the platform). Access control inside the database uses MongoDB's own built-in roles (read, readWrite, readAnyDatabase, readWriteAnyDatabase, dbAdmin, dbAdminAnyDatabase, and clusterMonitor); this is database-level role assignment, distinct from the IONOS group-and-grant model, where the "Access and manage DBaaS" privilege controls who may open the Database Manager at all.

1.1 Editions and Topology

The edition decision is the most consequential one in this unit, because it is effectively permanent. Moving from Business to Enterprise is a platform migration (a manual data move into a newly provisioned cluster), not an in-place resize, and downgrades are not supported. Choose the edition for where the workload will be in a year, not where it starts.

The following table is the IONOS edition comparison; use it to place a workload before you provision anything.

Above the two production editions sits Playground: a fixed 1 vCPU / 2 GB RAM / 50 GB single instance, intended for testing and explicitly excluded from any SLA. Treat it as a sandbox only, never as a staging stand-in for a production cluster.

Topology follows the edition. Business is always a single replica set with a node count of 1 or 3 (use 3 in production for high availability). Enterprise replica sets extend to 5 or 7 nodes for read distribution and resilience, and only Enterprise can shard. Sharding is horizontal scaling: collections are partitioned across shards by a shard key, with a minimum of 2 shards (the count can be increased but not decreased). Each sharded cluster also auto-provisions three config-server instances (2 cores / 4 GB / 40 GB storage each) that are excluded from your billed resources; total billed resources are the per-node resources multiplied by the number of instances and the number of shards. Enabling sharding on a collection requires the enableSharding role.

Reach for sharding only when a single instance hits a vertical wall. A single Enterprise instance scales to 31 vCPU and 230 GB RAM, supports roughly 114,000 connections, and caps at 30,000 write IOPS (reached around a 600 GB volume) and about 600 MB/s sequential throughput. Cross those thresholds (working set above 230 GB, connection demand above ~114,000, or write IOPS above 30,000) and you shard to aggregate capacity across shards; below them, a vertically scaled replica set is simpler and cheaper. For FinCorp, the fraud-event store starts as a 3-node Business replica set, with a documented path to Enterprise if event volume forces a working set past the single-node RAM wall. Note one connection-management consequence: IONOS does not provide a managed connection pooler for MongoDB, so the connection ceiling is a hard application-side budget. Drivers must pool connections themselves.

1.2 Designing Around the Two Boundaries

No managed change-stream replication. IONOS does not offer managed cross-cluster replication for MongoDB: you cannot point one managed cluster at another and have the platform stream changes between them. The native pattern is application-level change capture, exactly the substitution introduced in Unit 1.3. The application (or a MongoDB change-stream consumer it runs) publishes change events to Managed Kafka (Unit 5.6), and downstream consumers project those events wherever they are needed. For FinCorp, fraud-scoring outcomes are published as events rather than replicated at the database layer, which also gives the analytics tier a clean event feed without coupling it to the operational store.

Backup Service does not cover managed databases. The Acronis-based Backup Service (Unit 5.7) protects VMs and Block Storage only; it does not back up Managed MongoDB. Database continuity is delivered entirely by the cluster's own backup model. The platform takes a base snapshot when the cluster is created (initial sync, usually under 24 hours), after every restore, every 24 hours, and a full snapshot every Sunday. Snapshots are retained for seven days, and you can restore from any snapshot taken with the same or an older MongoDB patch version. Point-in-time recovery, which lets you restore to a chosen moment between 1 and 24 hours in the past (default 24 hours), is Enterprise-only. Restores are in-place into the same cluster and can use only that cluster's own snapshots; only one restore job runs at a time, and the cluster is busy during a restore and must not receive connections. For long-horizon retention beyond seven days, or for migrating data in or out, the path is mongodump / mongorestore, the same dump/restore discipline as the relational tier. The Oplog underpins replication and PITR: size it to hold at least 24 hours of history; it can be resized later without downtime using replSetResizeOplog. Enterprise clusters can also place off-site backups in a region different from the cluster's own (de, eu-south-2, eu-central-3), which is how FinCorp keeps a geographically separate copy under German data residency.

Managed MongoDB inherits the standard DBaaS SLA structure: a 3-or-more-node HA setup carries a 99.95% per-service uptime commitment, a single- or dual-node cluster carries 99.9%, and Playground carries no SLA. This is one more reason FinCorp's production fraud store runs 3 nodes from day one.

2. DCD Implementation Walkthrough

We will provision FinCorp's fraud-event store: a 3-node MongoDB Business replica set on the private data LAN of the existing FinCorp VDC, then connect to it from an in-VDC client. This realises the document tier of the layered architecture, sitting private-only behind the application tier exactly as the relational cluster does. MongoDB has no automatic IP address management and the only supported subnet is /24, so the network must be prepared first.

Prerequisites: the FinCorp VDC with a dedicated private LAN; at least one client server attached to that LAN that can resolve public DNS (the database is reached over a mongodb+srv name); the "Access and manage DBaaS" privilege on your group; and one free private IP per instance (three IPs for a 3-node cluster), chosen so they do not collide with the DHCP range. On an IONOS-DHCP /24, pick addresses between x.x.x.3/24 and x.x.x.10/24, which DHCP never assigns.

Build goal: Provision a cluster and connect.

Steps (in the Data Center Designer):

1. Open the Database Manager for MongoDB and click Create cluster. The Resource allocation panel shows used and unused contract quota; the cluster counts against it.
2. In Properties, set a meaningful Cluster Name, choose the Location (the data center / region holding the data; pick a German region for FinCorp residency), and select the MongoDB Version (6.0 or 7.0).
3. Choose the Edition. Select Business, then pick a Template sizing the RAM / vCPU / storage from the predefined list. (Enterprise instead exposes the flex resource sliders and the replica-set-vs-sharded-cluster choice plus the BI Connector toggle; Playground is the fixed free sandbox.)
4. Set the node count to 3 instances for the production replica set (Business supports 1 or 3).
5. In Network configuration, select the Datacenter and the private Datacenter LAN from the drop-down, then enter one IP/Subnet per instance. Use the free private IPs reserved in the prerequisites; this is what keeps the cluster private-only.
6. Set the Maintenance window: choose a Day and a Start Time (UTC). Maintenance runs in a fixed 4-hour window, so pick a genuine low-traffic slot rather than leaving it arbitrary.
7. Review the estimated price, then click Save to provision. The cluster enters a creation state and becomes available shortly after.
8. To connect, open the cluster's Cluster details tab and copy the Connection URI (it has the form mongodb+srv://m-<id>.mongodb.<region>.ionos.com). From a client on the same private LAN, run mongosh against that URI with your database username and password. The connection must come from an in-VDC client, because the endpoint is private only.

Common mistakes:

• Do not pick the edition casually. Business to Enterprise is a manual platform migration, not a resize, and downgrades are unsupported. Size the edition for the workload's future, not its first week.
• Reserve and record your private IPs before you start, one per instance, inside the safe x.x.x.3 to x.x.x.10 band on an IONOS-DHCP /24. The only supported subnet is /24, and the cluster does no IP management for you, so a collision with the DHCP range or another server breaks the build.
• Do not try to reach the cluster from outside the VDC or expect a public endpoint; the connection must originate from a client on the same private LAN. The client must still resolve public DNS to look up the mongodb+srv name.
• Do not assume the Backup Service protects this database. It does not. Continuity is the cluster's own snapshots (7-day retention), Enterprise-only PITR (1 to 24 hours), and mongodump / mongorestore for anything longer-lived or for migration.
• Set a real maintenance window. It is a fixed 4-hour slot during which managed operations run, so place it in a low-traffic period.
• Plan connection counts against the per-instance ceiling (about 114,000 on a 230 GB Enterprise node) and pool in the driver. There is no managed connection pooler to absorb a connection storm.

Summary

Managed MongoDB is FinCorp's document tier: the home for irregular, fast-evolving aggregates like the fraud-event store and customer-360, while the relational cluster keeps the ledger. The edition choice is effectively permanent (Business to Enterprise is a manual migration), so it is sized for the future, and topology follows from it: Business is a single replica set, Enterprise adds larger replica sets and sharding for workloads that breach the single-instance walls. The cluster is built private-only on a /24 LAN with one reserved IP per node and reached over a mongodb+srv URI from an in-VDC client. Two boundaries shape the design: no managed change-stream replication, so changes propagate via application-level events into Kafka, and no Backup Service coverage for databases, so continuity rests on the cluster's own snapshots, Enterprise PITR, and dump/restore.

Key Points:

• Choose document over relational when records are self-contained, schema-flexible aggregates read as whole objects; keep multi-row ACID and SQL analytics on the relational tier.
• Edition is near-permanent: Business (single replica set, 1 or 3 nodes) vs Enterprise (5/7-node replica sets, sharding, BI Connector, PITR); Business to Enterprise is a manual platform migration, not a resize.
• Shard only past a single Enterprise instance's walls (230 GB RAM, ~114,000 connections, 30,000 write IOPS); minimum 2 shards, plus three unbilled config servers.
• Provision private-only on a /24 LAN with one free IP per instance in the DHCP-safe range; connect with mongosh over the mongodb+srv URI from an in-VDC client.
• There is no managed change-stream replication; propagate changes with application-level event publishing to Managed Kafka.
• The Backup Service does not cover managed databases; continuity is the cluster's 7-day snapshots, Enterprise-only PITR (1 to 24 hours), and mongodump / mongorestore.

Important Terminology:

• Replica set: a group of MongoDB instances holding copies of the same data for redundancy and high availability; the only Business topology and the simpler Enterprise topology.
• Sharded cluster: an Enterprise-only horizontal-scaling topology that partitions collections across shards by shard key (minimum 2 shards) plus three unbilled config servers.
• Oplog: the operation log underpinning replication and point-in-time recovery; size it for at least 24 hours of history and resize online with replSetResizeOplog.
• PITR (point-in-time recovery): restoring to a chosen moment between 1 and 24 hours in the past; Enterprise-only and in-place into the same cluster.