What is MongoDB?
Author: Domeny.ForSale editorial team Published
In brief: MongoDB is a document database: it stores information in structures resembling JSON objects, rather than organising it exclusively in tables with rows and columns. It is useful, among other things, in applications where data has a nested structure or varying sets of attributes. However, it is not automatically a faster or simpler alternative to SQL databases — the choice depends primarily on how data is written and read.
How MongoDB stores data
MongoDB belongs to the NoSQL family, a group of systems that do not rely exclusively on the traditional relational model. The basic unit of data is a document: a set of fields and values describing, for example, a product, user or order. Documents are grouped into collections, which serve a similar purpose to tables but do not require every record to have an identical set of fields.
A document can be represented in readable JSON form:
{
"_id": "product-101",
"name": "Urban backpack",
"priceGrosz": 18900,
"colours": ["black", "navy"],
"specifications": {
"capacityLitres": 20,
"waterproof": true
}
}
The _id field is the document’s unique identifier. If the application does not supply one, an ObjectId identifier will usually be assigned during a standard document insertion. The remaining fields can contain text, numbers, lists and further documents, among other things.
Internally, MongoDB uses BSON, a binary document format that also supports data types not directly available in JSON, such as dates. Saying that MongoDB “stores JSON” is therefore a useful simplification rather than an exact description of its storage format.
How MongoDB differs from an SQL database
Relational databases, such as PostgreSQL or MySQL, organise data in tables and allow it to be joined using shared fields. For example, an orders table can reference a customers table. SQL is a language used, among other things, to query such databases.
In MongoDB, related information is often placed within a single document. An order can contain a list of items and the delivery address at the time of purchase. This allows the application to retrieve all the data it needs without assembling it from multiple separate structures.
| Area | MongoDB | Relational database |
|---|---|---|
| Main structure | Documents in collections | Rows in tables |
| Data model | Natural nesting and lists | Explicitly defined columns and relationships |
| Relationships | Embedded data or references | Foreign keys and joins |
| Queries | Document operations and aggregation pipelines | SQL queries |
This comparison does not imply a rigid division of capabilities. Relational databases can support JSON, while MongoDB allows data from collections to be joined, including through the $lookup operation. It also supports transactions spanning multiple documents, although their cost and deployment requirements need to be taken into account in the project.
A flexible schema does not mean no rules
Documents in a single collection can have different fields. In a shop catalogue, a backpack might have a capacity in litres, while a monitor has a screen diagonal and resolution. There is no need to create an identical set of empty columns for every type of product.
Flexibility does not, however, remove the need to design a data model. If one part of the application stores a price as a number and another as text, filtering and calculations become more difficult. MongoDB offers schema validation: rules that check required fields and their types, among other things.
You also need to decide what to embed in a document and what to store a reference to. A delivery address saved in an order should usually remain a historical snapshot. It is better to store the customer’s current profile separately rather than update copies of it in every order.
You should not keep adding data to a single document without limits. MongoDB has a BSON document size limit of 16 MiB, so a constantly growing event history usually requires a separate collection.
When to choose MongoDB and when to consider PostgreSQL
MongoDB is a sensible candidate when an application works with complex objects whose contents are often read together. Examples include a product catalogue with varying attributes, a content management system or device configurations. The mere fact that an application uses JavaScript is not a sufficient reason to choose it.
A relational database is worth considering first when the main priorities are numerous relationships, integrity constraints between tables and reports that combine many types of data. This applies, for example, to a billing system, where ease of managing dependencies may matter more than flexibility in document structure.
Before deciding, write down the application’s three most common operations, such as finding a product, retrieving a shopping basket and saving an order. Then prepare a sample model in both databases. Check how many reads and updates each operation requires and where copies of the same information are created.
How to get started and what to remember when deploying
You can run MongoDB on your own infrastructure or use MongoDB Atlas, a managed cloud service. Tools for working with data include the MongoDB Compass graphical tool, the mongosh shell and programming language drivers. Check the official documentation and the pricing for your chosen plan for current Atlas prices, limits and backup coverage.
To begin, create a test collection, add a dozen or so documents and run typical queries. Then choose indexes, additional structures that speed up searches, to match your actual filters and sorting. Too many indexes take up space and increase the cost of writes.
Before deploying to production, configure authentication, network access restrictions and backups, and test data restoration. Use the first prototype to check the model and queries — only measuring them against representative data will allow you to assess whether MongoDB suits a particular application.
See also: What is 2FA?
Read also
