Database · in regular use
MongoDB agency in Nice
The document database we use where the data has no stable shape from one record to the next.
What we do with it
MongoDB at our clients, concretely
We use it alongside PostgreSQL, never instead of it: heterogeneous documents, third-party API responses kept as they came, event histories whose shape keeps changing. We do not move a relational database to a document store without a reason that can be measured.
The limits
When we recommend something else
As soon as the data has stable relationships and constraints to enforce — invoices, stock, accounts — PostgreSQL protects it better, and for longer.
Our work
Projects we delivered with MongoDB
LLM Monitor
SaaS that measures how visible brands are in AI answers.
MongoDB: Storage of AI answers, whose format varies from one model to another.
Read the LLM Monitor case study
Method
How we bring MongoDB into a project
Before writing any code, we draw the line between what goes into MongoDB and what stays in PostgreSQL, then settle how the two connect: usually the PostgreSQL record's identifier stored in each document, so an API response or an event can be tied back to the business record it concerns. Every collection gets its indexes when it is created, designed around the searches the application will actually run, plus an expiry period where data loses its value over time, as event histories do.
In development, MongoDB runs in a container on the same version as production. The automated tests deliberately insert incomplete or older-format documents to check that the code reads them without failing. Format changes go through transformation scripts versioned in the repository, run at deployment and replayable against a copy.
Backups of both databases are restored together during testing, because a document cut off from its relational record no longer means anything. On delivery you receive the joint restore procedure, administration accounts created in your name and the list of indexes with the search each one serves.
For your business
What it changes in practice
Your users never see MongoDB. What they notice is that a supplier changing its data format, or a new kind of document turning up, causes neither an outage nor a wait: the application records the information as it arrives, and the way it is used adapts afterwards. Your invoicing and stock data stay protected in the relational database, so a badly formed external source cannot damage them.
The trade-off should be clear from the start: an extra engine is one more thing to monitor, update and bring back after an incident. We keep that manageable by confining MongoDB to the data that needs it, checking that both databases come back together in a consistent state, and leaving the scripts and procedures in the repository, which belongs to you from day one. Another provider can then take over the whole setup without relying on us, and you know in advance which features would be affected if either database had to be restored.
Our reading of it
What we take away from MongoDB
MongoDB is justified when the shape of the data is not stable: documents whose fields vary from one source to the next, event histories with heterogeneous structures, readings from sensors or APIs whose format changes without notice. In those cases, forcing a relational schema means adding empty columns and satellite tables for nothing.
That flexibility has a price worth stating up front: whatever the schema no longer checks, the application code must check, and that discipline slips quickly. As soon as the data has a known shape and relationships to enforce, we lean towards PostgreSQL, or MySQL when the hosting dictates it. The natural stack around it stays Node.js, where the same JSON objects are handled from end to end.
Decision guide
Should you choose MongoDB?
MongoDB or PostgreSQL as the main database for our application?
PostgreSQL, in the large majority of cases. If your data describes customers, orders, invoices or stock, it has stable relationships and rules that must hold, and a relational database enforces them in the engine itself. We add MongoDB alongside when part of the data changes shape from one record to the next: heterogeneous documents, third-party API responses, event histories. The main database stays relational; the document store is a targeted addition.
Should third-party API responses go into MongoDB or into PostgreSQL JSON columns?
It depends on volume and use. If you keep a handful of responses for auditing or debugging, a JSON column in PostgreSQL is enough and spares you a second engine to maintain, back up and monitor. MongoDB earns its place when those documents form a dataset in their own right, queried on varying fields and fed continuously by several sources whose format changes without warning. A second engine carries a real running cost: usage has to justify it, not convenience.
Can a small team realistically run MongoDB as well as PostgreSQL?
That is the question to settle before adding MongoDB. Two engines mean two backup procedures, two access policies and two streams of security updates. For a team of two or three developers, we keep MongoDB for cases where it removes genuine complexity from the code, for instance when every new data format would otherwise force a change to the relational schema. Without that measurable gain, PostgreSQL on its own is easier to look after over the years.
Client questions
What clients ask us about MongoDB
Is our data less safe in MongoDB than in a traditional database?
Not inherently, but the safeguards work differently. Out of the box, MongoDB accepts documents with differing structures, so a missing or mistyped field can slip through unnoticed. We add validation rules to collections, switch on authentication, restrict network access and encrypt connections. For accounting or contractual data we stay with PostgreSQL, which enforces those constraints at the heart of the engine.
Could another provider take over an application built on MongoDB?
Yes. MongoDB is widely known among developers and well documented. Takeovers rarely stumble on the engine itself; they stumble on nobody having described what the stored documents look like. Because the database imposes no schema, we record the expected structure of each collection and its validation rules in the project repository. A developer joining later knows what to expect instead of reverse-engineering it from the data.
Can we migrate our existing MongoDB database to PostgreSQL?
Yes, and it is sometimes the right call when data that has since become stable, such as customers or orders, was put into MongoDB by default. We first take stock of the formats actually present in the collections, which often differ from what the documentation claims. We then move the structured data into relational tables and leave in MongoDB whatever remains genuinely heterogeneous. The switch has to fix an identified problem.
Can MongoDB run on our own server, or do we need an online service?
Either works. MongoDB can be installed on your server, often in a container, or rented as a managed service from a hosting provider. The managed service handles upgrades and backups, in exchange for a subscription and data hosted outside your premises. Running it on your own server keeps the data in-house but leaves the day-to-day operation with you. We compare both options in the costed action plan, before any money is spent.
What happens if the MongoDB server fails?
It depends on the setup chosen. With a single server, the features relying on MongoDB stop until it is restored, and anything written since the last backup is lost. MongoDB can also keep several synchronised copies on separate machines: if one goes down, another takes over automatically. That redundancy raises hosting costs, so we propose it when losing access to the data in question would genuinely bring your business to a halt.
Going further
MongoDB sits within our Software development
A technology does not make a project. The method around it decides the outcome: scoping, prototypes, short cycles, and a clean way out.
Neighbouring technologies
A MongoDB project in mind?
The first conversation is free. We will tell you plainly whether this technology is the right one, and if not, which is.
Updated on