MongoDB vs Postgres: Why We Have Recommended MongoDB for a Decade
This debate usually opens with "which one is better" and goes nowhere. Our position rests on more than a decade of practice: we use MongoDB on our projects without exception.
That is not a matter of principle, it is the result of accumulated experience. Even on the most complex relational structures we have not needed anything else. But there is a condition attached, and it is the real subject of this article.
First, the honest part: you have to know NoSQL
MongoDB feels easy to us because of how we model, not because of the tool itself.
The most common mistake we see is using MongoDB with relational habits. A separate collection per entity, references between them by id, then trying to stitch it all back together on every query. Used that way MongoDB genuinely becomes hard work, and people are right to conclude they should have used Postgres.
The correct approach is the opposite: store data the way it is read. If an order screen shows the line items, the delivery address and the status history together, keeping them in one document makes sense. Instead of joining five tables you perform one read.
This does not mean abandoning normalisation. It means deciding what to embed and what to reference based on access patterns.
How we model
In practice three rules are enough.
What is read together stays together. Data always shown on one screen belongs in one document: an order and its items, a user and their preferences, an event and its participant summary.
What grows independently lives apart. If a document would grow without bound, it moves to its own collection. A product's reviews can reach thousands over time, so embedding them in the product document is wrong.
Small, frequently changing data lives apart. Putting a counter updated every second inside a large document creates unnecessary write load.
For a team that knows these three rules, even the most complex business domain models comfortably.
Are relational structures really not a problem?
We get this question a lot, and it is a fair one.
MongoDB's aggregation pipeline is more capable than most teams realise. Cross-collection joins, grouping, conditional computation and window functions are all there. We write reporting queries in that layer.
Transactional integrity is no longer a talking point either. Multi-document ACID transactions have existed since 4.0 and they work. We use them where several records must change consistently, such as a funds transfer.
But one point deserves emphasis: if your model requires joining six collections on every query, the problem is not MongoDB. It means you designed a relational schema and put it in a document database.
What it changes day to day
The difference shows up in maintenance more than in benchmarks.
Schema changes are not a migration project. Adding a field to the product means no table alteration, no lock, no maintenance window. You start writing the new field; old records simply do not carry it, and the code handles both states during the transition.
On fast-moving products that is worth a lot. We delivered Sportez in eight weeks; the data model changed repeatedly during that time and not one change required a migration meeting.
Horizontal scaling is built in. Sharding is part of the architecture rather than a layer added later. When growth arrives you add servers.
Operational load is light. Backups, replicas, monitoring and automatic failover come as standard, and on a managed service they are already configured.
When we recommend Postgres
In fairness, our preference is MongoDB but there are cases where Postgres is the better call.
The client's internal team knows SQL and will take the system over. If the people maintaining it after handover are comfortable with PostgreSQL, imposing our preference would be wrong.
The existing infrastructure is already relational. Where an enterprise runs SQL Server or Oracle and the new system will work closely with it, staying in the same world is sensible.
Heavy analytical querying is the main job. For a system where BI tools connect directly and complex SQL reports get written, a relational database is more comfortable.
Geospatial work or specialised extensions are required. Mature extensions like PostGIS do not always have an equivalent.
In short
We have recommended MongoDB for a decade because maintenance is straightforward, schema changes are painless, scaling is built in, and it does not slow the development pace on fast-moving products.
But the condition bears repeating: you have to know NoSQL. A document database used with relational habits makes everyone unhappy. For a team that models around access patterns, we have not needed Postgres even on the most complex business domains.
If you want to work through this decision on your own product, bring the three queries you run most often and the answer to who maintains the system after handover. The decision usually falls out of those two.