MongoDB

What is MongoDB?

MongoDB is the most popular document database. Instead of storing data in the rows and columns of a relational table, it stores documents — flexible, JSON-like structures (technically BSON) that can nest objects and arrays and vary in shape from one document to the next. A record isn’t spread across joined tables; the whole thing lives in one document. That flexibility, plus a developer-friendly experience and easy horizontal scaling, made MongoDB the default “NoSQL” choice for a generation of applications — and also the default mistake for teams that actually needed a relational database.

When the document model fits — and when it doesn’t

The document model shines when data is naturally document-shaped and the schema evolves quickly: content management, product catalogs, user profiles, event/activity data, and early-stage products where the shape of things changes weekly. You can add fields without migrations, store an entire aggregate (an order with its line items) as one document you fetch in a single read, and scale out with sharding built in. Where it hurts is highly relational data with lots of many-to-many relationships and cross-entity transactions. MongoDB can do joins ($lookup) and does now support multi-document ACID transactions — but if your data is fundamentally relational and your queries constantly join across entities, you’re fighting the tool: you’ll either denormalize and duplicate data (with the consistency headaches that brings) or bolt relational patterns onto a database not optimized for them. The honest rule: choose MongoDB when documents match your access patterns, not because “SQL is old.” A huge share of MongoDB pain comes from teams picking it for relational workloads that Postgres would have served better — and modern Postgres with its JSONB type can even cover many document use cases, narrowing MongoDB’s unique advantage.

Schema flexibility is a responsibility, not a free lunch

“Schemaless” is the most misunderstood MongoDB selling point. The database not enforcing a schema doesn’t mean your data has no schema — it means the schema is now your application’s responsibility, and without discipline you get “schema drift”: five years of documents in slightly different shapes, optional fields that are sometimes missing, type inconsistencies, and query code littered with defensive checks. Mature MongoDB use adds schema validation back (MongoDB supports JSON-schema validation rules) precisely because unconstrained flexibility becomes a data-quality liability. Other realities: data modeling is access-pattern-driven (like most NoSQL — you model around how you’ll read, deciding what to embed vs reference), indexing discipline matters as much as in any database (unindexed queries scan collections and crawl), and the classic operational footguns are unbounded document growth and arrays that grow without limit. Managed MongoDB Atlas removes most of the operational burden and is how most teams run it today.

What people get wrong

• Choosing it for relational data — heavy many-to-many joins and cross-entity transactions fight the document model; a relational database fits better.
• Treating “schemaless” as no schema: without validation and modeling discipline, data drifts into inconsistent shapes that pollute every query.
• Ignoring indexes and document growth — unindexed queries scan whole collections, and unbounded documents/arrays degrade performance over time.

Primary source: MongoDB documentation