MongoDB

Three strengths

• Data shaped like your app. It stores information in flexible, JSON-like documents, so the data matches how the application code uses it. 1
• Change without downtime. Its flexible schema lets you evolve your data model without downtime and handle records that differ from one another. 1
• Grows with your data. If a server drops out, the cluster automatically elects a new one, and data can be spread across many machines as you grow. 1

What it is

A database is where an app keeps its records so they survive when the app is closed. Many databases, such as PostgreSQL and SQL Server, keep records in tables with a fixed set of columns. MongoDB takes a different approach. It's a document database, where each record is a document: a bundle of labelled fields, much like the JSON format web apps already use to pass data around. A field can hold a plain value, a list, or another whole document, so a customer's record can carry their address and order notes inside it. 1

Documents live in collections, which MongoDB compares to tables, with one big difference: they "do not enforce a rigid, pre-defined schema". 1 A schema is the fixed layout of fields a table expects, so without one, two records in the same collection can look different. That suits information whose shape keeps changing.

MongoDB came out of a scaling problem. Its founders, Dwight Merriman, Eliot Horowitz and Kevin Ryan, were veterans of the online advertising company DoubleClick, where they "quickly learned the limitations of relational databases" while serving more than 400,000 ads per second. 2 They founded the company, then called 10gen, in 2007 and launched MongoDB, short for "humongous database", in 2009. The company renamed itself MongoDB in 2013. 2

It belongs to a family that researchers call "NoSQL" data stores. In a 2010 survey, database researcher Rick Cattell described these systems as built to scale simple application loads over many servers, and noted that they typically sacrifice some properties, such as database-wide transaction consistency, to gain others, such as availability and scalability. 3 MongoDB has moved on since: it now supports multi-document transactions, which let you run several reads and writes as a single all-or-nothing event. 1

It's well used: 24% of developers surveyed in 2025 said they use it. 4

We choose it for records that don't sit neatly in fixed columns, where the freedom to add or change a field without rebuilding the database saves a lot of time.

How we use it

We choose MongoDB for flexible, changing records, where the shape of the data differs from one record to the next or keeps evolving as your product does. For a typical new build our default is PostgreSQL, and where a client runs on Microsoft we use SQL Server.

In Software Development, it lets your app's data change shape as the product grows, without a rebuild each time. In Data Solutions, it's one of the stores we connect to when information arrives in mixed shapes. In Solution Architecture, it's an option we weigh against the others, so the database we recommend matches how your data behaves.

References

1. MongoDB, "Introduction to MongoDB", MongoDB Manual. https://www.mongodb.com/docs/manual/introduction/ (accessed 28 October 2026)
2. MongoDB, "Our Story", mongodb.com. https://www.mongodb.com/company/our-story (accessed 28 October 2026)
3. Rick Cattell, "Scalable SQL and NoSQL Data Stores", ACM SIGMOD Record, vol. 39, no. 4, December 2010, pp. 12-27. https://sigmodrecord.org/publications/sigmodRecord/1012/pdfs/04.surveys.cattell.pdf (accessed 28 October 2026)
4. Stack Overflow, "2025 Developer Survey: Technology", survey.stackoverflow.co, 2025. https://survey.stackoverflow.co/2025/technology (accessed 28 October 2026)