Lv.2 BeginnerMongoDB

2026.04.1320 min readLv.2 Beginner

SeriesMongoDB ACID Mastery · Part 1View series hub

MongoDB ACID — Part 1: "NoSQL with transactions?" — ACID and MongoDB's evolution

The old line that NoSQL has no transactions is no longer accurate for MongoDB. What changed is not a binary switch but a gradual expansion: single-document atomicity was there for a long time, while multi-document and distributed transactional scope arrived in stages — and you need that timeline to read today's manual limits fairly. This Part 1 maps the four ACID letters to operational questions, walks the 4.0 and 4.2 story, and resists the oversimplified CAP slogan in favor of what partition actually means. It also spells out the real costs of adopting transactions — contention, latency, retries — and ends with a short decision flow: model inside one document first, then pay for multi-document work only when invariants demand it. Across five installments, later parts go deeper on each ACID axis (starting with Atomicity & Consistency in Part 2, then Isolation, Durability, and production patterns); consider this the grounding episode.

Series outline

• Part 1 — ACID concepts + MongoDB’s historical context (this post)
• Part 2 — Atomicity & Consistency in depth: single document vs multi-document
• Part 3 — Isolation levels and snapshot isolation internals
• Part 4 — Durability, WiredTiger, Write Concern (forthcoming)
• Part 5 — Production patterns, performance, anti-patterns (forthcoming)

Table of contents

1. Introduction — "NoSQL with transactions?"
2. What is ACID?
3. MongoDB and ACID — myths and history
4. Why ACID is hard in NoSQL — beyond CAP, and the cost of transactions
5. When do you need multi-document transactions? — a short decision flow
6. Closing — Part 1 summary

1. Introduction — "NoSQL with transactions?"

In 2018, when MongoDB shipped version 4.0, many practitioners were genuinely surprised.

"NoSQL databases support ACID transactions?"

Since then, MongoDB has outgrown the label of a simple "NoSQL database." Multi-document ACID transactions, high-availability deployments, and enterprise-grade security and compliance features are all part of the story — and public references where MongoDB sits alongside mission-critical stacks in finance, healthcare, and e-commerce have grown. Still, it is hard to justify claims like "always the #1 choice in the market" with a single metric: hiring, references, workloads, regulation, SLAs, and existing team skills all matter.

This series aims to go beyond textbook definitions of MongoDB’s ACID behavior and into internals and trade-offs. This first installment frames what ACID asks of a system and how far MongoDB has supported those guarantees over time.

2. What is ACID?

Everyone memorizes the four letters early on; fewer people connect them to running systems. Here we treat each letter as an operational question.

Atomicity

Everything in a transaction must commit together or roll back together.

For a transfer between accounts, debiting one account without crediting the other would destroy money. Atomicity prevents that half-done outcome.

Consistency

The database must remain in a valid state before and after the transaction: schema rules, domain invariants, and integrity constraints hold. (Depending on context, "consistency" also means application-defined invariants.)

Isolation

Concurrent transactions must not observe each other's intermediate states; they should appear to run alone. What anomalies remain (dirty reads, phantoms, etc.) depends on isolation level — MongoDB’s specifics are for Part 3.

Durability

Once a result is successfully committed, it must survive later failures. Data acknowledged as "saved" should still be there after a restart. Disks, replication, and Write Concern are Part 4.

3. MongoDB and ACID — myths and history

3.1 Early years (2009–2017): "NoSQL means no ACID?"

MongoDB’s early story emphasized flexible schema and horizontal scale. Multi-document transactions across collections were not available in the product, and that gap fueled criticism.

Saying "there was no ACID at all" is misleading. Even then, MongoDB guaranteed atomic updates at the single-document level: reads and writes to one BSON document, including nested arrays and sub-documents, applied or rolled back as a unit. The real debate was less "ACID vs not" than where the supported transaction boundary ended.

3.2 Turning point: MongoDB 4.0 (2018) — multi-document ACID on replica sets

In June 2018, MongoDB 4.0 introduced multi-document ACID transactions for replica sets: transactions spanning multiple documents and collections.

3.3 MongoDB 4.2 (2019) — sharded clusters

Where 4.0 focused on replica sets, 4.2 extended transactional support to sharded clusters, enabling distributed transactions while keeping horizontal scaling in play.

Exact constraints depend on deployment topology (standalone vs replica set vs sharded); always read the manual for your server version.

3.4 Today — how to read the narrative

MongoDB is routinely evaluated for enterprise workloads, but adoption is driven by regulation, downtime tolerance, team skills, and stack fit — not a single leaderboard. Sweeping lines like "every bank runs only MongoDB" do not match reality; weigh public references and your own constraints.

4. Why ACID is hard in NoSQL — beyond CAP, and the cost of transactions

4.1 CAP and distributed systems

CAP is often taught as "pick two of consistency, availability, and partition tolerance." More carefully, the interesting case is when the network partitions: which guarantees you prioritize under partition is the heart of the discussion — not a universal slogan for every normal operation.

Many distributed stores, MongoDB included in its early years, did not enforce strong synchronous consistency on every operation in exchange for latency, availability, and scale. Multi-node ACID transactions necessarily add synchronization and consensus cost.

4.2 Document modeling and "natural" atomicity

Good document design can reduce the need for multi-document transactions. If data that would be split across tables in a relational model fits in one document, a single-document atomic update often suffices.

// Example: one order as one document (illustrative)
{
  _id: ObjectId("..."),
  orderId: "ORD-2026-001",
  customerId: "CUST-123",
  status: "confirmed",
  items: [
    { productId: "PROD-A", qty: 2, price: 15000 },
    { productId: "PROD-B", qty: 1, price: 32000 }
  ],
  totalAmount: 62000,
  createdAt: ISODate("2026-04-09T00:00:00.000Z")
}

If the boundary can live inside one document, you may not need a transaction across collections. Widen the document before you widen the transaction remains a useful design heuristic.

4.3 The cost of multi-document transactions

"Supported" does not mean "free."

• Contention: hot documents or index ranges mean waits and retries.
• Latency: consensus, logging, and lock acquisition interact with network RTT.
• Retries: clients should plan for labels like TransientTransactionError and implement retry policies.
• Topology: shard keys, sessions, and timeouts shape real-world behavior.

So: use transactions when needed; prefer single-document design when you can. Tuning and patterns are for Part 5; here we only fix that cost exists.

5. When do you need multi-document transactions? — a short decision flow

This is not a rigid rulebook — it is a question order common in design reviews.

1. Can you model the state in one document?
   Often yes for nested arrays and sub-documents — single-document operations are enough.

2. Is there an invariant across collections or documents?
   E.g. stock decrement and order confirmation, or paired debit/credit — then multi-document transactions enter the conversation.

3. Is the key hot?
   Even with transactions, you may need sharding and aggregation strategy; transactions are not a magic concurrency cure-all.

4. Can the application handle retries or compensating actions?
   Distributed systems rarely assume "success on the first try" only.

Typical cases that need multi-document work

• Transfers updating different documents that must move together.
• Cross-collection invariants such as orders and inventory.

Often handled with single-document atomicity

• $push / $pull for arrays
• $set on multiple fields
• $inc for counters

6. Closing — Part 1 summary

References

• MongoDB Manual — Atomicity of single-document writes
• MongoDB Manual — Transactions
• MongoDB Manual — Release Notes 4.0 — multi-document transactions
• MongoDB Manual — Release Notes 4.2 — distributed transactions
• MongoDB Manual — Transactions in applications — retries
• MongoDB Manual — Update operators
• CAP theorem — commonly misunderstood as a simple "pick two"; read it as trade-offs under network partition (distributed systems literature).

Written April 2026. Product versions, licensing, and cloud pricing change — cite official docs and release notes.