MongoDB stores documents rather than rows, with no fixed schema. It suits data whose shape genuinely varies between records — event logs, third-party payloads, product specifications that differ by category.
What is MongoDB?
MongoDB stores JSON-like documents in collections. Two documents in the same collection can have completely different fields, which is either liberating or terrifying depending on what you are storing.
Where it genuinely helps is data you do not control the shape of: webhook payloads from a dozen providers, sensor readings with varying attributes, product specifications where a laptop and a sofa share nothing.
Where it hurts is data that does have a fixed shape, which is most business data. Without a schema, nothing stops a typo in a field name creating a second field that looks fine until a report is wrong.
When we choose MongoDB
For one collection inside a larger system, where the shape is genuinely unpredictable. Event logs, integration payloads, audit records.
When the client already runs it and the team knows it well.
It also fits caching and denormalised read models — a pre-computed view of data that is expensive to assemble from the relational side, rebuilt on a schedule and read cheaply by the application.
When we do not use MongoDB
As the main database for a business application. Orders, invoices, customers and bookings have a fixed shape and relationships between them, and a relational database enforces both. Choosing MongoDB for that trades away guarantees you will want later, and we will say so.
Postgres also handles JSON columns well, which covers most "we need flexibility here" cases without giving up the schema everywhere else.
What we build with MongoDB
Event and integration stores
Raw payloads from external systems kept exactly as received, before being normalised into the relational side. Useful when a provider changes their format without telling anyone and you need the original.
Activity and audit logs at volume
High-write, append-only records where the shape varies by event type and the data is never updated after it is written. This is the workload Mongo genuinely suits.
Product catalogues with varying attributes
Where categories share almost no fields — a laptop has RAM, a sofa has upholstery — and forcing them into one relational table produces a hundred mostly-empty columns.
Webhook and integration inboxes
Every payload from an external system stored exactly as received before anything is done with it. When a provider changes their format without notice, the original is still there to replay against the fixed code.
How we ship MongoDB projects
With schema validation enabled. Mongo supports it, most projects do not use it, and without it the flexibility that made you choose it becomes the thing that corrupts your data.
Alongside a relational database rather than instead of one, in almost every case.
Indexes designed up front. Mongo will happily scan an entire collection to answer a query and give no indication that it did, which is fine at a thousand documents and catastrophic at a million.
What MongoDB costs you
No joins in the relational sense, so relationships are either duplicated across documents or resolved in application code — both of which are work a relational database would have done for you.
Transactions across documents exist but are more limited, which matters when an operation must either fully happen or not at all.
The bigger risk is organisational rather than technical. Without a schema, the shape of the data becomes whatever the application happened to write, and two years later nobody can say with confidence what fields exist or which are safe to rely on. Schema validation prevents that, and it has to be enabled deliberately.
Cost at scale is also worth modelling. Managed Mongo hosting is generally more expensive than managed Postgres for equivalent capacity, and self-hosting a replica set is more operational work than a single Postgres instance. Neither is a reason to avoid it where it fits; both are reasons not to reach for it by default.
MongoDB questions we get asked
Probably not as the main database. If your data is orders, customers and bookings, that has a fixed shape and relationships, and a relational database protects both. Mongo earns a place for the specific collection whose shape genuinely varies.
Yes, and that is how we usually deploy it. Postgres holds the records with relationships and rules; Mongo holds the collection whose shape genuinely varies. Choosing one for everything is what causes problems, not using both deliberately.
Across multiple documents, yes, with more constraints than a relational database and a performance cost. If your operations routinely need to change several records atomically, that is a signal the data is relational and belongs in Postgres.
Always, in our view. It keeps the flexibility where you want it and stops a typo in a field name silently creating a second field. Most Mongo data-quality problems we are asked to fix would not exist with validation enabled from the start.
For a simple lookup by key, marginally. For anything involving relationships, no — work a relational database does in one join becomes several queries or duplicated data in Mongo. The speed claim usually comes from comparing an indexed Mongo collection against an unindexed SQL table, which is not a comparison of databases.
Yes, and it is a common request from teams who picked Mongo early and now need transactions and constraints. The work is in deciding the schema — the documents will have accumulated inconsistencies, and agreeing what the data should actually look like is most of the project.
When you are storing something whose shape you do not control and will not be updating — webhook payloads, event logs, sensor readings, audit records. That is a real fit and Mongo handles it better than forcing it into a relational table. Outside that, we would ask what problem it is solving.