MongoDB engineering
MongoDB is a strong database when the document really is the unit of work, and a relational store fits the rest. This page is mostly about telling those apart, because the expensive version of this decision is discovering the mismatch in year two.
01Capabilities
Four places a document store genuinely earns its keep
A document store earns its place when the unit of work really is the document: written whole, read whole, and varying in shape for a reason. That is a real category and it is smaller than the category of projects that chose MongoDB. Where the questions cross documents instead, the decision belongs on our PostgreSQL page. Four cases where we reach for MongoDB without hesitating.
- Events
Event, telemetry and audit stores
High-volume writes of records that vary by event type, are almost never updated, and are read back by time and identifier. Device and session data from EV charging or fleet hardware is a natural fit, because the payload shape follows the firmware rather than a schema committee.
- Catalogue
Content and catalogue documents
Product entries, articles, configuration bundles and anything with deep optional nesting that gets rendered whole. In e-commerce this beats fifteen sparsely populated relational tables holding attributes that apply to one product category and no other.
- Projections
Read models you rebuild rather than migrate
MongoDB as a derived, disposable view of data whose source of truth lives elsewhere, usually a relational store. This is the most defensible pattern we use it in, because a read model that gets its shape wrong can be thrown away and regenerated.
- Inherited
An existing cluster made safe
Applications where collections have drifted, indexes were added under pressure, and nothing enforces document shape. Schema validation, an index review and a real migration approach usually fix the pain without changing the database at all. That work sits with our data engineering practice, under an ISO 27001:2022 certified information-security management system.
02Fit
Where the joins come back, and who writes them
For a new system, we test the reason you give for choosing MongoDB against what a document store actually solves. Often PostgreSQL answers it better, and where the document is the unit of work, MongoDB is the right engine. Each row below is the call we would make on the data you have.
| Your situation | What we recommend |
|---|---|
| The document is written whole and read whole, it varies by type for a real reason, and nothing has to report across entities | Use MongoDBThis is the case it was designed for, and it does it well. Model the boundary properly and the rest of the decade is quiet. |
| "We do not know the schema yet, so we want something flexible" | Different pageYou do have a schema. It moves into application code where nothing enforces it. PostgreSQL with a JSONB column keeps the flexible part flexible and leaves constraints available. |
| Orders, payments and inventory that have to stay consistent with each other | A relational databaseMulti-document transactions exist, and building a ledger on a database whose design assumption is the single document means fighting the tool at the most expensive moment. |
| Business reporting, and joins across collections, are a stated requirement | Move it outThe aggregation pipeline is powerful and it is not a substitute for SQL your analysts already speak. Feed a warehouse and leave the cluster doing one job. |
| You are about to run your own replica set, and nobody's job is database operations | Buy it managedManaged MongoDB from your own provider. Buy backups, patching and failover rather than staffing a rota you cannot fill, and spend the saved time on the data model. |
| A working application, with a shape problem rather than an engine problem | Stay putAdd JSON schema validation, fix the indexes, get a migration approach for document changes. Swapping engines to solve unenforced shape is expensive theatre. |
Scope
What we own on MongoDB work is the modelling decision and everything downstream of it. Whether the document boundaries hold as the product grows. Whether the indexes match the queries you will really run. What your path looks like when a shape has to change across every record. We work under an ISO 27001:2022 certified information-security management system. unicrew has been building systems like these since 2012, with 100+ senior in-house engineers across six countries. If a relational database fits your problem better, that is the design we propose before the contract.
We start from the product's unit of work, then choose the database. MongoDB is the right fit when what you load and what you save are the same shape. For relational data, we build on PostgreSQL, so a query planner handles the joins.
Oleksandr TrofimovChief Technology Officer, unicrew03Delivery
Settling the boundary before the collection fills up
Four decisions that separate a MongoDB codebase that is pleasant in year three from one nobody wants to open. All four are cheap now and awkward later.
- Find the real document boundaryWhat is embedded and what is referenced, decided from the read and write patterns rather than from how the objects happen to look in code. Get this wrong and you either update one enormous document from six places or reimplement joins in the application.
- Write the shape down and make the database enforce itCollection-level JSON schema validation, from the first release. Flexible does not have to mean unvalidated, and the difference shows up the first time a producer starts writing a field with the wrong type and nothing complains.
- Index for the queries, then check what the queries doExplain output on the real access patterns, including the aggregation stages. Collection scans hide well at development volumes and stop hiding at the worst possible moment, which is usually the first genuinely busy day.
- Rehearse a shape change before you need oneA versioned document approach and a tested backfill, because schema changes do not vanish with a schemaless database, they move to your side. Every one runs through the same QA and test automation practice we use on our own builds.
04Stack
What sits either side of a document store
The engines this choice is weighed against, and the layers around it. Each has its own page if that is the decision you are actually making.
05Questions
Asked before a schema is committed to anything
Answered the way we would answer them live. Ask yours on the call and the answer will be specific to your data.
Yes. We start by confirming that a document store is the right one, so your data model sits on the engine that fits the problem. Once that is settled, an architect outside the delivery team reviews the data model and changes go through the same QA practice as our own work. Team extension is managed teams; an outcome is data engineering.
PostgreSQL, unless the document really is your unit of work. Two questions decide it. Do you need reporting or consistency across entities? If yes, relational. Do your records vary in shape because the domain varies, or because nobody has decided yet? If it is the second, a document store just moves the decision into application code, where it is harder to fix. PostgreSQL also has JSONB.
Possibly, and it is rarely worth a migration to fix. Schema change does not disappear with a schemaless database. It moves from a migration script to a backfill job you write yourself, and to defensive code in every reader. On a working system the practical fix is JSON schema validation so the shape is declared, versioned documents, and the backfill tooling built once.
Operational lookups, yes. Business analytics, we would move the data out. The aggregation pipeline expresses most of what you want, and your analysts and their tools still speak SQL. Analytical scans on an operational cluster also compete with the writes you care about. The usual answer is a pipeline into a warehouse, with Spark in the path only if the volume justifies it.
A scoping call with an engineer. For a new system we want to hear how the data is read and written before anything about technology. For an existing one, the collection statistics, the index list and a few representative documents tell us most of what matters. You get back a written read on the modelling decision and what we would change first. Most engagements start within two to four weeks.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we only offer it once the first read is done, because a fixed number on a system nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
About to write joins in application code?
Describe how the data gets read and written, and how often the shape moves. You get a straight recommendation with the reasoning, document store or relational database, whichever your access pattern favours.