MongoDB Hosting: Self-Hosted vs Managed for Production

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

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 27017 to 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:

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.

Raff Managed MongoDB is still rolling out

The live Raff Managed Databases page currently lists MongoDB as rolling out. It also describes planned/current product positioning around replica sets and continuous backup, but the console should remain the source of truth for whether MongoDB can actually be deployed for your account and region.

Do not make a production architecture depend on Raff Managed MongoDB until deployment availability is confirmed.

The practical decision is:

Need MongoDB on Raff now
  -> self-host on Raff VM

Want Raff Managed MongoDB
  -> check live console availability
  -> if not deployable, use Raff VM or another suitable managed MongoDB service

This wording is deliberate: a product can appear in a public roadmap or rollout state before it is ready for every production account.

MongoDB hosting checklist before production

Before treating a deployment as production-ready, confirm:

• MongoDB is not broadly exposed to the public internet.
• Authentication and least-privilege users are configured.
• Production availability requirements are documented.
• Replica-set topology matches those requirements.
• RPO and RTO are defined.
• Backup storage is appropriate for the failure modes you need to survive.
• A restore has been tested.
• Monitoring covers connections, operation latency, storage, replication, and node health.
• Upgrade responsibility is clear.
• Storage growth is monitored.
• Application retry and failover behavior is tested.
• An engineer or provider clearly owns database incidents.

If several of these are difficult for the team to sustain, that is a strong reason to prefer managed MongoDB when a suitable managed service is actually available.

Conclusion: choose MongoDB hosting from the responsibility boundary

MongoDB hosting is not only a server choice. It determines who owns the database lifecycle when the system needs maintenance, scaling, recovery, or incident response.

Choose self-hosted MongoDB when host-level control, custom topology, or exact maintenance control is a real requirement and the team can sustain the operating work. Choose managed MongoDB when standard capabilities fit and reducing operational burden is more valuable than unrestricted host control.

On Raff, the deployable path today is self-hosted MongoDB on Raff VM. Raff Managed MongoDB is still marked as rolling out, so confirm availability in the live console before depending on it.

For the broader operating-model decision, continue with Managed vs Self-Hosted Databases.

Sources

• MongoDB Production Notes for Self-Managed Deployments
• MongoDB Deploy a Self-Managed Replica Set
• MongoDB Backup Methods for Self-Managed Deployments
• MongoDB Security Checklist for Self-Managed Deployments
• Raff VM
• Raff VPC
• Raff Data Protection
• Raff Managed Databases
• Product status reviewed: 2026-09-16; verify the live product page and Raff console for current MongoDB availability and service capabilities.