MongoDB
Where your data's rules live once you pick MongoDB
The short answer
MongoDB is a database that stores documents rather than rows in fixed tables, so two records in the same collection can hold different fields. That suits data which is naturally document-shaped and a product whose structure is still moving. It stops where many records must stay consistent with each other.
You can't judge a database by reading a proposal, and nobody expects you to. What you can judge is whether whoever picked it can explain what it does differently. With MongoDB that difference is real, and it lands on the rest of the build.
Documents instead of rows
A relational database keeps records in tables. Fixed columns, every row the same, and anything that doesn't fit gets refused at the door. MongoDB drops that rule. It stores documents, grouped into collections, and two documents in one collection can hold completely different fields without the database objecting.
So a customer isn't a row pointing at four other tables. It's one document with the addresses, preferences and order history nested inside, written and read back in one go.
That's the difference, and it sets the grain. MongoDB is good at writing and reading one whole thing, and less interested in questions that gather fragments from all over.
Rows in a fixed table
Documents in a collection
- Where the shape is set
Rows in a fixed table: In the database, before anything is stored.
Documents in a collection: In the code that writes it, every time.
- Adding a field
Rows in a fixed table: A change applied to every existing row.
Documents in a collection: Nothing to change, and old records still lack it.
- Reading one whole thing
Rows in a fixed table: Several tables joined on every read.
Documents in a collection: One document, if it was written that way.
- Keeping records in step
Rows in a fixed table: The database refuses bad writes, and loosening a rule is a migration.
Documents in a collection: No migration to run, and your code has to refuse them everywhere.
Where the document model genuinely fits
Some data is document-shaped and always was. A form where half the fields depend on the answers above them. A catalogue where a mattress and a table lamp share almost no attributes. Force those into fixed columns and you get forty mostly empty ones.
The other real fit is time. Early on, the shape of the data is a guess that changes every week it meets real users. Adding a field to a collection costs nothing; the same change against a few million relational rows is a planned migration. Worth a lot in month two, much less in year three.
The structure doesn't disappear, it moves
This is the part that's almost never in the proposal. Dropping fixed columns doesn't mean your data has no structure. The application still assumes this document has an email address and that this status is one of four values. Those assumptions moved out of the database and into the code. Read a relational table and you know what a record is. In MongoDB you read the application instead.
And the shapes accumulate. Documents saved two years ago have one form, this month's another, both in the same collection because nothing forced them to agree. Every read copes with both, or somebody rewrites the old ones. That costs more the longer the product runs.
There's a middle setting and it's underused. Validation rules on a collection make the database reject documents missing a required field or holding the wrong type. They stay off until somebody turns them on.
MongoDB as shipped
Nothing is refused. A document's shape is whatever last wrote it.
With validation on
Required fields and types enforced per collection, once somebody sets them.
Relational schema
Columns, types and relationships refused at the door, for every writer.
Rules live in your code
Rules live in the database
- Rules live in your code
MongoDB as shipped
Nothing is refused. A document's shape is whatever last wrote it.
With validation on
Required fields and types enforced per collection, once somebody sets them.
Relational schema
Columns, types and relationships refused at the door, for every writer.
- Rules live in the database
Where a relational database earns its keep
The clearest line is consistency across many records. When a change has to touch several of them and either all land or none do, a relational database was built for that and rejects the half-finished version itself. Money moving between accounts. A seat that must not be sold twice.
MongoDB can do this, and multi-document transactions work. The model still assumes that what changes together lives in one document, so a build needing a transaction on most of its writes is arguing with its database.
The second line is questions nobody planned for. Relational databases answer those in SQL, which most reporting tools already speak. The same query across several collections is more work, and your finance lead's tool may need a connector. Weigh that early if reporting matters much here.
Who has to be around afterwards
Two jobs, very different sizes. Running the database is the smaller one and you can buy it: MongoDB, Inc. sells a managed service called Atlas that handles backups, upgrades and failover. Run it yourself and you've taken on server copies, upgrades, backups somebody has actually restored, and index review.
The larger job never appears in a quote. Somebody has to hold the shape of the data, because the database won't. Written-down document shapes, validation rules where they matter, an answer for old documents when a shape changes. With one steady lead developer that's fine. Across two handovers it's what decays.
So ask which parts of this build store things and which parts have to keep things in agreement. That answer picks the database more reliably than any argument about the product.
Worth knowing before you start
Ask whoever is quoting to write down, for each collection, the fields every document is guaranteed to have. If that list doesn't exist, somebody reconstructs it from code later, at your expense.
Ask whether validation rules are switched on for the collections that matter. MongoDB can enforce required fields and types per collection, and it does nothing until a person sets it up.
Ask what happens to a document written two years ago when the shape changes. The honest answers are rewrite the old ones or handle both shapes forever, and the choice decides what year three feels like.
If money, stock or bookings are in scope, ask which single document holds the thing that must never go out of step. If the answer spans several, ask what happens when one write succeeds and the next fails.
Ask who reviews indexes and how often. A collection that was fast at ten thousand documents and slow at ten million is usually missing an index, not short of a bigger server.
Common questions
Not inherently. It can be quicker at reading one whole record stored as a single document, because there's nothing to join. It's slower than people expect when a query has no index. At your likely size, speed comes down to indexes and query shape, not the name on the product.
Yes, across multiple documents, though that arrived long after the first release. The design still nudges you toward keeping whatever changes together inside one document. If most writes need a transaction across several collections, that's a signal the data was modelled for a different kind of database.
The server is free to download and run on hosting you pay for. MongoDB, Inc. also sells Atlas, a managed service priced by cluster size, with a free tier for experiments. Check their pricing on the day. The company controls the server's licence and has changed it before, aimed at providers reselling MongoDB rather than at businesses using it. If you'd host it for your own customers, have someone read the current terms.
The documents export. The code doesn't. Everything in your application that assumed a particular document shape gets rewritten, a bigger job than swapping a website platform, because more of the database's work was being done in your code.
Maybe, and one question will tell you. Ask which records have to stay consistent with each other, and what they'd store instead. An answer naming the records and the risk is worth listening to. One that's really about preference isn't, in either direction.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.