Why isn't 'majority' the default read concern in MongoDB?

Source: Dev.to

TL;DR

If you’re used to traditional SQL databases and synchronous request‑response flows—where you read your writes in the same transaction or session—use the majority read concern in MongoDB. It gives you the highest isolation and durability you can expect from a database.

• It isn’t the default, but it’s safe to change it for your connection.
• The default is optimized for event‑driven, micro‑service architectures with asynchronous communication, where lower latency is preferred even if it means sometimes reading a state that may later be rolled back.

Why MongoDB Doesn’t Enable the Strongest Consistency by Default

PostgreSQL users typically expect writes to become visible to other sessions only after they’re acknowledged, either via auto‑commit DML or an explicit COMMIT.

In MongoDB you must enable the majority read concern to achieve similar ACID guarantees, and this is not the default.

It may seem surprising that MongoDB offers the strongest consistency option—full ACID semantics in a distributed database—yet doesn’t enable it by default, despite apparently modest performance impact.

This discrepancy prompted a deeper look into the reasoning behind the design choices.

Historical Context: SQL vs. NoSQL

• SQL standard: Isolation levels were first defined by the anomalies (phenomena) that can occur when concurrent sessions read and write the same data.

  • These definitions were tied to a lock‑based implementation rather than an abstract model; they assumed reads and writes use locks and that active transactions share a single current database state.

• Modern databases often choose different designs for scalability:

Isolation & Durability in MongoDB

To understand isolation and durability in MongoDB, we must first consider read and write concerns independently—especially in a replicated, distributed setup where reads and writes can hit different servers. Then we can examine how they interact when we read after writing.

Isolation vs. Durability (the I and D in ACID)

Originally these definitions assumed a single‑node database. In modern systems durability must also handle network and data‑center failures, so data is persisted across multiple nodes rather than just on a local disk.

Typical Commit Flow (SQL‑style)

1. Commit is initiated.
2. WAL is flushed to local disk – local durability.
3. WAL is flushed to remote disk – global durability.
4. Changes become visible (end of isolation) to other sessions.
5. Commit is acknowledged in the client session.

The order above matches:

• PostgreSQL with synchronous_commit = on, or
• MongoDB with w:majority and a majority read concern in the reading sessions.

Other configurations reorder these steps:

The “Missing” Default: Why Not Use the Strongest Sequence?

The strongest isolation‑and‑durability sequence (steps 1‑5 above) isn’t the default in MongoDB. One reason is an additional anomaly that the SQL standard never described because it assumes read and write locks on a single database state are mutually exclusive.

MVCC Introduces Two Logical Times

1. Read time – the start of the transaction (or start of the statement in Read Committed). All reads use a snapshot from this time.
2. Write time – the end of the transaction; all writes appear atomically at commit.

Because read time …

Key takeaway: In MVCC systems, applications often notify other services before the write acknowledgment arrives, assuming the write is already complete. This expectation is only safe when the read concern ensures the write is both durable and visible.

Summary

• majority read concern in MongoDB provides the strongest isolation and durability, comparable to the default behavior of many SQL databases.
• It isn’t the default because MongoDB targets event‑driven, low‑latency micro‑service architectures, where the trade‑off of occasional stale reads is acceptable.
• The causality anomaly introduced by MVCC (read‑time …)

Tip: When using w:1, select the local read concern to avoid this anomaly. w:1 is not the default; it is chosen only when lower latency is preferred over guaranteed durability.

Latency vs. Durability Trade‑offs

• Local acknowledgment (w:1 / synchronous_commit = local)

  • Pros: Lower latency; writes complete quickly.
  • Cons: Higher risk of losing events on failure (writes may be rolled back).

• Majority acknowledgment (w:majority / synchronous_commit = on)

  • Pros: Stronger durability; writes survive node or data‑center failures.
  • Cons: Extra network latency because the system waits for remote acknowledgments.

Even with majority acknowledgment, a read‑after‑write anomaly can appear if microservice B reads before the majority has committed the write. Using MongoDB’s local read concern eliminates the anomaly but may expose data that could later be rolled back.

Default Read Concern and Its Rationale

• The default read concern (often “majority” for MongoDB) aligns well with event‑driven architectures, which were a primary use case for early NoSQL systems.
• Developers typically expect reads to return the latest changes, even if those changes haven’t been fully acknowledged in the originating thread.

Traditional Architectures

When MongoDB is used in more traditional, durability‑focused setups:

• “majority” read concern is preferred.
• No additional performance penalty is incurred because the write latency has already been paid while waiting for the write acknowledgment.

How “majority” works:

• Sets the read timestamp to the last committed time while keeping reads local.
• May block briefly in rare situations (e.g., instance startup, rollback, unavailable or lagging secondaries).
• Generally, there is no noticeable performance impact.

MongoDB’s Configurable Consistency Model

Unlike many SQL databases that enforce a one‑size‑fits‑all consistency guarantee for every DML operation, MongoDB places more responsibility on developers to choose the appropriate consistency and performance settings.

Key Configuration Options

1. Write Concern – determines durability

   • Example: w:majority for resilience against network or data‑center failures.

2. Read Concern – determines the visibility guarantees of reads

   • Examples:
     • majority – reads the most recent majority‑committed data.
     • snapshot – provides stronger consistency for multi‑shard transactions.

3. Read Preference – determines where reads are routed

   • Allows scaling reads across replicas, tolerating some staleness when acceptable.

By tuning these three knobs, MongoDB can adapt to a wide range of consistency and performance requirements.