MongoDB hosting means running MongoDB on infrastructure you operate yourself or using a managed database service that operates more of the database platform for you.
For production teams, the important decision is not simply where MongoDB runs. It is who owns patching, replica sets, backups, restore tooling, monitoring, failover, capacity changes, and database incidents.
Raff Technologies supports self-hosted MongoDB on cloud VMs today. Raff Managed MongoDB is listed on the live Managed Databases page as rolling out, so it should not be treated as a deployable production dependency until availability is confirmed in the Raff console.
If you need MongoDB on Raff now, the practical path is a Raff VM with private networking and a MongoDB architecture your team operates. If reducing database-platform responsibility matters more than host-level control, compare managed MongoDB services and verify whether Raff Managed MongoDB is available for your account when you deploy.
MongoDB database hosting: quick decision
| Decision area | Self-hosted MongoDB | Managed MongoDB |
|---|---|---|
| Operating-system access | Full control | Usually abstracted |
| MongoDB installation | Your team | Provider |
| Patching and maintenance | Your team | Mostly provider-operated |
| Replica-set deployment | Your team | Service-dependent |
| Backups | Your design and tooling | Provider tooling within service scope |
| Restore workflow | Your team owns full process | Provider workflow + application validation |
| Monitoring | Your stack | Usually included to a defined scope |
| Failover operations | Your team designs and tests | Usually provider-operated when HA is enabled |
| Custom agents/packages | Flexible | Often restricted |
| Schema and indexes | Your team | Your team |
| Application credentials | Your team | Your team |
| Query performance | Your team | Your team |
| Best fit | Teams needing host/topology control | Teams prioritizing lower operations burden |
Choose self-hosted MongoDB when a documented requirement needs root access, custom packages, specific topology, exact maintenance timing, or deep control over MongoDB configuration.
Choose managed MongoDB when standard service capabilities fit and the team wants the provider to own more of the database platform.
The wrong reason to self-host is that starting one mongod process is easy. The right reason is that the control you gain is worth the ongoing operating responsibility.
What MongoDB hosting actually includes
MongoDB hosting is more than compute and storage.
A production deployment needs answers for:
- where database nodes run;
- how application traffic reaches them;
- authentication and authorization;
- TLS and private networking;
- replica-set topology;
- backups and retention;
- historical or point-in-time recovery requirements;
- monitoring and alerting;
- version upgrades;
- storage growth;
- failover behavior;
- restore testing;
- on-call ownership.
Two MongoDB hosting providers can expose the same database engine while giving the customer very different operational responsibilities.
That responsibility boundary is what should drive the decision.
How to compare MongoDB hosting providers
For commercial searches such as MongoDB hosting, MongoDB database hosting, or MongoDB hosting providers, compare equivalent production capabilities rather than headline RAM alone.
Availability model
Ask whether the product is:
- one database node;
- a replica set;
- a multi-zone replica set;
- a sharded cluster;
- or simply a VM on which you build those layers yourself.
A single server and a production replica set are not equivalent hosting products.
Backup and recovery scope
Check:
- backup frequency;
- retention;
- whether historical or point-in-time recovery is available;
- whether restores create a new deployment or replace the existing one;
- whether recovery can be tested safely;
- whether backups remain usable when the primary deployment fails;
- who validates the application after restore.
“Backups included” is not enough to define recoverability.
Private networking and access control
Evaluate:
- private endpoints or VPC connectivity;
- IP allowlists or firewall controls;
- TLS;
- scoped database credentials;
- authentication logging;
- whether normal application-to-database traffic can remain off the broad public internet.
Version and maintenance policy
Check which MongoDB versions are actually deployable and how the provider handles:
- minor updates;
- major upgrades;
- maintenance windows;
- rollback limitations;
- compatibility testing.
Self-hosting gives more control here, but the team also owns testing and rollback planning.
Observability
Production teams usually need visibility into:
- connections;
- operation latency;
- slow queries;
- index behavior;
- storage growth;
- replication lag;
- elections and failovers;
- CPU and memory pressure;
- backup state.
Managed hosting can provide more of this within the service. Self-hosted deployments need an explicit monitoring model. See Database Monitoring for Small Teams for the broader monitoring framework.
Scaling model
Understand whether scaling means:
- resizing one node;
- increasing storage;
- adding replica members;
- adding read capacity;
- introducing sharding;
- or migrating to another service tier.
Compare the scale path you are likely to use, not the largest cluster shown on a pricing page.
Total operating cost
The real comparison can include:
- compute;
- storage;
- replica members;
- backups and retention;
- data transfer;
- high availability;
- monitoring;
- support;
- engineering maintenance;
- incident and on-call work.
The infrastructure bill is only one part of MongoDB hosting cost.
Self-hosted MongoDB fits workloads that need deeper control
A cloud VM is a practical MongoDB hosting model when the team needs direct operating-system and database control.
Common reasons include:
- custom operating-system packages;
- exact MongoDB version selection;
- exact upgrade timing;
- direct access to MongoDB configuration and logs;
- custom monitoring or security agents;
- specific TLS or authentication integrations;
- custom replica-set placement;
- backup tooling controlled by the team;
- integration with private infrastructure;
- requirements outside a managed database catalog.
A development environment may run one MongoDB node. A production environment that requires database-level availability normally needs a replica-set design rather than assuming one VM is highly available.
A simple self-hosted production pattern can look like:
Application -> private network -> MongoDB replica set -> primary -> secondary -> secondary Backup target -> separate recovery location
This architecture adds resilience, but it also adds systems your team must patch, monitor, secure, back up, and recover.
For installation, use How to Install MongoDB on Ubuntu 24.04.
Managed MongoDB fits teams that want less database-platform work
Managed MongoDB is useful when the application needs MongoDB semantics but operating MongoDB infrastructure does not create product differentiation.
Depending on the provider and plan, a managed service may reduce work around:
- provisioning nodes;
- replica-set operations;
- host patching;
- routine maintenance;
- backup scheduling;
- restore tooling;
- metrics and alerting;
- storage expansion;
- failover;
- controlled upgrades.
The application team still owns:
- document structure;
- embedding versus references;
- indexes;
- aggregation pipelines;
- transaction boundaries;
- credentials;
- query behavior;
- data-retention decisions;
- application behavior during failover;
- validation after restore.
Managed MongoDB solves an operations problem. It does not make MongoDB the correct data model for an application that is fundamentally relational.
If the engine choice is still open, compare MongoDB vs PostgreSQL, MongoDB vs MySQL, or MySQL vs PostgreSQL vs MongoDB.
Self-hosted MongoDB vs managed MongoDB cost
The cheapest server is not necessarily the cheapest production system.
A useful self-hosted model is:
Self-hosted MongoDB TCO = database infrastructure + storage + backup storage + monitoring + maintenance engineering + incident/on-call work + upgrade and recovery work
A managed model is closer to:
Managed MongoDB TCO = managed service price + HA / storage / backup charges where applicable + application-side database engineering
Self-hosting can be economically attractive when the team already has mature database automation and can spread operational work across many deployments.
Managed hosting can be economically attractive when database operations would otherwise consume scarce engineering time or create unacceptable incident risk.
Do not compare one inexpensive VM with a managed production replica set. Compare equivalent availability, backup, monitoring, recovery, and support assumptions.
Production MongoDB needs replica-set planning
MongoDB replica sets provide redundancy and election behavior for self-managed deployments.
Replication does not replace backups.
Replication can copy unwanted changes such as:
- accidental deletes;
- destructive updates;
- application bugs;
- incorrect data mutations.
Replication supports service continuity. Backups provide historical recovery.
Production planning should define:
- replica-set member count;
- member placement;
- election behavior;
- application retry behavior;
- replication-lag monitoring;
- how failed members are rebuilt;
- how the cluster is validated after failover.
If those responsibilities are not something the team can operate confidently, that strengthens the case for a managed service.
MongoDB backup and restore should start from RPO and RTO
Define two targets first:
- RPO — how much recent data the application can afford to lose.
- RTO — how long the application can tolerate the database being unavailable or in recovery.
Then design:
- backup frequency;
- retention;
- backup location;
- restore procedure;
- restore testing;
- recovery ownership;
- application cutover after recovery.
A successful backup job is not the same as a successful recovery plan.
For self-hosted MongoDB, use a MongoDB-aware or topology-appropriate backup method. For managed MongoDB, verify exactly what the provider's backup and restore scope includes.
For a general production recovery framework, use Database Restore Testing: RPO, RTO, and Recovery Validation.
MongoDB should not depend on broad public exposure
For self-hosted MongoDB, prefer private networking or tightly restricted access.
A production security baseline includes:
- enable access control;
- separate administrative and application users;
- use least privilege;
- restrict port
27017to trusted paths; - prefer private application-to-database traffic;
- use TLS where required by the network path;
- rotate credentials;
- remove unused users;
- monitor authentication failures;
- keep the operating system and MongoDB maintained.
For a same-VM development setup, binding MongoDB only to localhost may be appropriate. For multi-server production, use private addresses and explicit firewall policy rather than broad public listeners.
MongoDB sizing starts with the working set
There is no universal MongoDB VM size.
Size from measured workload signals:
| Signal | Why it matters |
|---|---|
| Active working set | Determines how much frequently accessed data and indexes compete for memory |
| Index size | Influences memory and storage pressure |
| Document size | Affects storage, network transfer, and read/write behavior |
| Read/write ratio | Changes CPU, storage, and replica pressure |
| Connection count | Affects concurrency and memory use |
| Aggregation complexity | Can increase CPU and temporary working requirements |
| Storage growth | Drives capacity and backup planning |
| Replication lag | Shows whether secondaries can keep up |
| Backup duration | Affects recovery planning |
| Replica count | Multiplies infrastructure and storage requirements |
Start development workloads small if appropriate, then size production from observed data.
Do not solve every MongoDB problem by adding CPU or RAM. Missing indexes, inefficient aggregation pipelines, uncontrolled document growth, poor schema boundaries, and retry loops can remain slow on larger infrastructure.
Common MongoDB hosting architectures
Development: single VM
Application -> MongoDB on one VM
Suitable for development, prototypes, tests, and noncritical internal workloads.
It is not a substitute for a high-availability production design.
Production: separate application and database
Internet -> application -> private network -> MongoDB
This reduces database exposure and lets application and database resources change independently.
Production HA: replica set
Application -> private network -> MongoDB replica set -> member A -> member B -> member C
This improves database-level availability but increases operational responsibility when self-hosted.
Managed MongoDB
Application -> restricted or private database endpoint Managed MongoDB service
The provider operates more of the database platform while the application team continues to own data model and query behavior.
MongoDB hosting on Raff today
Raff currently has two relevant paths, but only one should be considered generally available without checking the console.
Self-hosted MongoDB on Raff VM
A Raff VM gives the team a full Linux environment and host-level control.
For MongoDB, your team owns:
- installation;
- authentication and authorization;
- version and upgrade decisions;
- replica-set design;
- monitoring;
- MongoDB-aware backup and restore design;
- restore testing;
- capacity planning;
- database security configuration;
- incident response.
A common Raff architecture is:
Public traffic -> application VM -> Raff VPC -> MongoDB VM or replica set
Raff VPC can keep database traffic on private network paths rather than exposing MongoDB directly to the public application path.
Raff Data Protection can provide an additional VM-level recovery layer where appropriate, but it should not replace MongoDB-aware recovery design when the workload requires transactional or historical database recovery.
