MongoDB — FAQ

Is it true that MongoDB "doesn't support transactions" or "isn't ACID"?

No, and this is a genuinely outdated claim worth actively correcting if you encounter it — MongoDB has supported multi-document ACID transactions since version 4.0 (2018) for replica sets, and 4.2 for sharded clusters. Single-document operations have always been atomic in MongoDB, with no special configuration needed. What is true, and probably where the outdated claim originates, is that MongoDB's own guidance often recommends designing schemas to rely on single-document atomicity where possible, since multi-document transactions carry a real performance cost — that's a design recommendation, not a technical limitation.

Since MongoDB is schema-flexible, does that mean I don't need to plan a schema at all?

Schema flexibility means MongoDB doesn't enforce a rigid structure at the database layer by default — it doesn't mean structure doesn't matter. In practice, real applications still need a deliberate, consistent schema (which fields exist, what embedding vs. referencing looks like for each relationship, what indexes support the actual query patterns) — the flexibility is about how easily that schema can evolve over time without a disruptive migration, not about skipping schema design entirely. An application built with zero schema planning, just inserting whatever shape of document happens to be convenient at the time, accumulates real technical debt just as surely as a poorly-planned relational schema does — MongoDB's $jsonSchema validator even exists specifically to let you add enforcement back in once a schema stabilizes.

Why does embedding sometimes get called "denormalization," and is that automatically a bad thing?

Embedding does duplicate data in the sense that traditional relational normalization would avoid — if the same author information appears embedded in every one of their blog posts, updating that author's name means updating it in every post document, rather than one row in an authors table. This isn't automatically bad; it's a genuine tradeoff, trading update complexity/consistency risk for read performance (fetching a post with its author info embedded is a single document read, versus needing a JOIN or a second query in a relational or referenced-document design). It becomes a real problem specifically when the duplicated data changes frequently or needs to stay perfectly consistent everywhere it's duplicated — which is exactly why this course's own material recommends referencing for "frequently updated sub-documents" specifically, not embedding as a universal default.

What's the actual risk of MongoDB's default write concern (`w: 1`) that makes stronger write concerns worth the performance cost sometimes?

w: 1 acknowledges a write once the primary confirms it, without waiting for that write to actually replicate to any secondary. In the rare case where the primary crashes moments after acknowledging a write but before replicating it, that write can be lost entirely if a secondary without it gets elected as the new primary — the application already told the user "success" for a write that no longer exists anywhere. For most data, this rare-event risk is an acceptable tradeoff for the speed of not waiting on replication acknowledgment; for genuinely critical writes (payments, orders), { w: "majority", j: true } closes this gap at a real, measurable latency cost — see this course's own Real World Scenarios material for the full failure mode this specifically addresses.

Is a `COLLSCAN` in `explain()` output always bad?

Not always — for a genuinely small collection, or a query expected to return most of the collection's documents anyway, a collection scan can actually be faster than the overhead of using an index (an index helps most when it lets the database skip examining the large majority of non-matching documents; if most documents match anyway, that benefit shrinks). The real signal to watch is the ratio between totalDocsExamined and nReturned in the execution stats — a query examining hundreds of thousands of documents to return a few hundred is a clear sign an index would help; a query examining roughly as many documents as it returns is often fine even via COLLSCAN, depending on collection size.

Why do people recommend hashed sharding for some fields but warn against it for others?

Hashed sharding evenly distributes writes by hashing the shard key value before assigning it to a shard — this is exactly the right property when write distribution matters most and you don't need efficient range queries on that field (a userId field where queries mostly do exact-match lookups, not ranges). It becomes the wrong choice when your application genuinely needs efficient range queries on the sharded field, since hashing destroys the natural ordering that makes range queries efficient in the first place — a range query on a hash-sharded field has to scatter across every shard rather than targeting a contiguous range on one or a few shards. The right choice depends entirely on whether your actual query patterns need range queries on that specific field.

Is MongoDB Atlas (the managed cloud service) meaningfully different from self-hosted MongoDB, or just a hosting convenience?

Beyond hosting convenience, Atlas includes genuinely additional capabilities not present in self-hosted community MongoDB by default — Atlas Search (Lucene-powered full-text search, covered in this course's own Advanced material), built-in monitoring dashboards, automated backups, and simplified scaling/sharding management. Core database functionality (CRUD, aggregation, replication, sharding concepts) is the same underlying MongoDB engine either way — the differences are mostly in operational tooling and a few Atlas-exclusive features layered on top, not a fundamentally different database.

Why does a replica set need a minimum of 3 members instead of just a primary and one secondary?

With only 2 data-bearing members, if the primary fails, the remaining secondary can't achieve a majority vote on its own (1 out of 2 isn't a majority) to safely elect itself as the new primary without real risk of a split-brain scenario if network connectivity is the actual problem rather than the primary being truly down. A third member — either a full secondary (preferred, since it can also become primary if needed) or an arbiter (vote-only, no data, cheaper but can't ever become primary itself) — ensures a majority is always achievable among the remaining members after any single node failure, which is the actual mechanism automatic failover depends on.

Does using MongoDB mean I should avoid SQL databases and relational thinking entirely?

Not at all — many real applications use both, choosing per use case rather than treating it as an all-or-nothing decision. A common real pattern: MongoDB for the flexible, document-shaped parts of an application (user profiles, content, catalogs), and a relational database for parts genuinely needing strict schema enforcement, complex multi-table joins, or mature reporting tooling (financial records, inventory systems with complex relational constraints). Treating "MongoDB vs. SQL" as a single company-wide choice, rather than a per-use-case one, often leads to forcing a poor fit in one direction or the other for at least part of the actual system.

Why does this course emphasize testing failover (`rs.stepDown()`) rather than just trusting that MongoDB's automatic failover works?

Because "the mechanism is documented to work" and "it actually works correctly for your specific setup, under your actual write patterns and network conditions" are different claims — this is the same reasoning behind DR testing generally covered elsewhere in this course's broader material (see the HA/DR technology's own emphasis on this exact point). A replica set that's never had failover actually tested might have a subtle configuration issue (priority settings that don't reflect the intended preferred primary, a write concern that behaves unexpectedly under real in-flight-write conditions) that only surfaces during a genuine failover event — testing it deliberately, on your own schedule, is what catches this before a real, uncontrolled incident does.