Use case · Databases
MongoDB hosting
MongoDB is a document-oriented NoSQL database storing flexible, JSON-like documents, suited to certain data and access patterns rather than the relational model. Hosting it well means ample memory for the working set, fast storage, replica sets for availability, and sharding for scale. Self-hosted on dedicated EU hardware, it gives control, performance, and European sovereignty.
Key points
- MongoDB is a document database storing flexible, JSON-like documents rather than relational tables.
- Its flexible schema suits data and access patterns that don't fit the relational model well.
- Performance depends on the working set — the active data — fitting in memory.
- Replica sets provide high availability with automatic failover; sharding provides horizontal scale.
- Self-hosting on EU hardware gives control and European sovereignty over the data.
What is MongoDB, and why host it?
MongoDB is a document-oriented NoSQL database, which stores data as flexible, JSON-like documents rather than in the tables of a relational database. This document model lets each record be a structured document, with its own fields and nested data, offering a different way of modelling data from the rows and columns of relational systems. MongoDB is widely used for applications whose data and access patterns suit this document approach, and it is valued for the flexibility of its schema and the way its document model can map naturally onto the objects applications work with.
Hosting MongoDB well means providing infrastructure suited to how it works, which differs in some respects from hosting a relational database. MongoDB's performance depends heavily on memory, it uses a particular storage engine, and it provides its own mechanisms for availability and scaling — replica sets and sharding — that shape how it is deployed. Like any database it needs fast storage, ample memory, and reliable hosting, but the specifics of MongoDB reward hosting attuned to them. This page focuses on MongoDB; the general considerations of database hosting apply and are covered on the database-hosting page.
The document model and flexible schema
MongoDB's defining characteristic is its document model, in which data is stored as documents — structured, JSON-like objects — rather than being spread across relational tables. A document can hold fields, nested documents, and arrays, representing a record's data together in one structure, which can map naturally onto the way an application represents its data in code. This differs fundamentally from the relational model, where data is normalised into related tables and joined together when needed, and it gives MongoDB a different set of strengths and trade-offs.
The schema flexibility that comes with this is significant: MongoDB does not require a fixed, predefined schema in the way relational databases traditionally do, so documents in a collection can vary in structure, and the data model can evolve without the rigid schema changes relational systems require. This flexibility suits applications whose data is varied or evolving, or whose structure does not fit neatly into fixed tables. It is a genuine difference in approach, and understanding it is central to understanding when MongoDB fits — the document model and flexible schema are what MongoDB offers in place of the relational model's structure.
When MongoDB fits — and when relational fits better
The honest position is that document databases like MongoDB and relational databases suit different data and access patterns, and neither is simply better. MongoDB fits well where data is naturally document-shaped, where the schema is flexible or evolving, where the access patterns retrieve documents whole rather than joining across many tables, and where horizontal scaling across many servers is wanted. Relational databases fit well where data is highly structured and relational, where complex queries join across many entities, and where the guarantees and standardisation of the relational model matter. Many applications could use either, and the right choice depends on the data and how it is used.
Choosing MongoDB should follow from the data and access patterns suiting the document model, not from a general assumption that NoSQL is newer or better. Where the document model fits the application's data and the flexibility and scaling MongoDB offers are valuable, it is an excellent choice; where the data is relational and complex querying across entities matters, a relational database may serve better. We host both document and relational databases and will not pretend one universally beats the other. Understanding MongoDB's fit — the document model, flexible schema, and horizontal scaling it offers — clarifies when it is the right tool, which is a matter of matching it to the workload rather than following fashion.
Memory: the working set
MongoDB's performance depends heavily on memory, specifically on the working set — the portion of data and indexes that is actively used — fitting in memory. When the working set is held in memory, MongoDB serves it quickly; when the working set exceeds available memory, MongoDB must read from storage more often, and performance degrades. This makes providing enough memory to hold the working set one of the most important factors in MongoDB performance, much as the buffer pool is for some relational databases.
Sizing memory for MongoDB therefore means providing enough that the actively-used data and indexes fit in memory, so that the common operations are served from memory rather than storage. What constitutes the working set depends on the application's access patterns — how much of the data is actively used — and memory should be sized to hold it. A MongoDB deployment with enough memory for its working set performs well; one whose working set spills out of memory suffers. We provide ample memory sized to the working set of the MongoDB workload, because keeping the active data in memory is central to MongoDB performing to its potential, and under-provisioning memory is a common cause of poor MongoDB performance.
Storage and durability
MongoDB uses a storage engine — WiredTiger by default — that manages how data is stored on disk, with compression and mechanisms for durability, so fast, reliable storage matters for the data that is not in memory and for persisting writes. Even with the working set in memory, data must be stored durably, and data beyond the working set is read from storage, so storage speed affects both durability and the performance of access to less-active data. Fast NVMe storage suits MongoDB by providing the throughput its storage operations need.
Durability in MongoDB comes from writes being persisted to storage and from mechanisms the storage engine and database provide to keep data safe, so reliable storage underpins the safety of the data. As with any database, the durability of MongoDB's data depends on writes being safely recorded, which reliable storage supports. Fast, dependable NVMe storage therefore underpins both MongoDB's performance for data not in memory and the durability of its data. We provide fast, reliable storage sized to the MongoDB workload, so that the data beyond the working set is served well and the durability MongoDB provides rests on storage that records writes dependably.
Replica sets: high availability
MongoDB provides high availability through replica sets — groups of MongoDB servers holding copies of the data, with automatic failover if the primary fails. In a replica set, one server acts as primary and others as secondaries holding copies of the data; if the primary fails, the replica set automatically elects a new primary from the secondaries, so the database continues available without manual intervention. This automatic failover is a built-in MongoDB feature for high availability, letting a MongoDB deployment survive the failure of a server.
Deploying MongoDB for high availability therefore means running it as a replica set across multiple servers, so that the failure of any one is handled automatically. The secondaries stay current with the primary and stand ready to take over, and can also serve read queries in some configurations. Running a replica set across multiple servers — ideally with appropriate separation so a single failure does not affect several — is how MongoDB achieves availability. When we host MongoDB, providing the multiple servers and arrangement a replica set needs is part of serving deployments that require high availability, using MongoDB's own replica-set mechanism to keep the database available through failures.
Sharding: horizontal scaling
For datasets or workloads too large for a single server, MongoDB provides sharding — distributing data across multiple servers, or shards, so that the data and load are spread horizontally. Sharding partitions the data across shards, each holding part of it, so that together they hold a dataset larger than one server could, and handle a load greater than one server could serve. This horizontal scaling is one of MongoDB's notable capabilities, allowing it to scale beyond the limits of a single machine by adding shards.
Sharding is more involved than a single server or a replica set, since it distributes data across many servers and requires the data to be partitioned sensibly, so it is used when scale genuinely demands it. For workloads whose data or load exceeds what one server can handle, sharding lets MongoDB scale out across many servers; for smaller workloads, a single server or replica set suffices without the complexity of sharding. Deploying a sharded MongoDB cluster means providing the multiple servers the shards and their coordination require. When a workload's scale calls for it, we provide the infrastructure for a sharded MongoDB deployment, so that MongoDB's horizontal scaling can be used to handle data and load beyond a single server.
Self-hosted MongoDB, sovereignty, and where we fit
MongoDB's community edition is freely available to self-host, though its licensing — the Server Side Public License — mainly restricts offering MongoDB itself as a managed service to third parties, rather than self-hosting it for your own application. For an organisation running MongoDB for its own use, self-hosting the community edition is the normal, permitted case, and it gives full control over the database and its data. Self-hosting on EU infrastructure adds European sovereignty: VV Internet Hosting is incorporated in the Netherlands, within the EU, so a MongoDB database self-hosted with us keeps its data under European jurisdiction and outside the direct reach of the US CLOUD Act, on infrastructure you control.
This aligns naturally with what we provide. We host the dedicated infrastructure on which you self-host and run MongoDB for your own application — ample memory for the working set, fast storage, and the multiple servers replica sets and sharding need — in EU datacenters under European jurisdiction; we do not offer MongoDB as a managed service, which is a different kind of offering and the part the licence particularly concerns. This suits organisations self-hosting MongoDB that want performance, control, and European sovereignty on infrastructure they command. We are clear about the boundary: we are the sovereign, dedicated infrastructure for self-hosting MongoDB, not a managed MongoDB service. If self-hosting on infrastructure you control fits your needs, we can host it well.
Related use cases
See also
Questions
MongoDB, answered plainly
Common questions about hosting for MongoDB.
How is MongoDB different from a relational database?
MongoDB is a document database: it stores data as flexible, JSON-like documents rather than in relational tables. A document holds fields, nested data, and arrays together, and the schema is flexible rather than fixed. This suits data that's naturally document-shaped or evolving, and access patterns that retrieve documents whole rather than joining across many tables — a different approach from the relational model.
Why does memory matter so much for MongoDB?
MongoDB's performance depends on the working set — the actively-used data and indexes — fitting in memory. When it does, MongoDB serves it quickly; when the working set exceeds available memory, MongoDB reads from storage more often and performance degrades. Providing enough memory to hold the working set is one of the most important factors in MongoDB performing well.
How does MongoDB provide availability and scale?
Availability comes from replica sets — groups of servers holding copies of the data, with automatic failover electing a new primary if one fails. Scale comes from sharding — distributing data across multiple servers so the data and load spread horizontally beyond a single machine. Replica sets suit availability; sharding suits datasets or loads too large for one server.
Planning MongoDB infrastructure?
We host dedicated, EU-sovereign infrastructure sized to your workload — and we will tell you plainly when something else fits better. Tell us what you're building.