MongoDB supports ACID transactions, but its guarantees depend on what you are changing and how the database is configured. A write to one document is atomic by itself. To make changes across multiple documents or collections all-or-nothing, use a transaction on a replica set or sharded cluster. Read concern, write concern, and server version also affect what reads can see and when acknowledged writes are durable.
What ACID means in MongoDB
ACID stands for atomicity, consistency, isolation, and durability. MongoDB provides these properties at different boundaries: a single-document write is atomic by default, while a multi-document transaction extends atomic commit across documents or collections. The exact guarantees for reads and acknowledged writes depend on the concerns you select and your deployment.
That distinction matters: MongoDB is not simply “ACID” or “not ACID.” The relevant question is whether the operation that protects your application’s invariant is one document write or a multi-document transaction, and what guarantees the application needs from reads and acknowledgments.
Atomicity: one document by default, multiple documents in a transaction
Single-document writes
A write that changes one document is atomic. Readers do not see that document halfway through a multi-field update. This makes a document a useful boundary for keeping related state consistent when the application can model it together.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →#1 Best Overall
Operations that affect multiple documents
An operation that modifies multiple documents is not atomic as a whole merely because it is issued as one operation. Each document modification is atomic, but other operations can interleave, and some changes may be visible even if the overall application task has not finished.
Multi-document transactions
A transaction lets multiple reads and writes across documents or collections commit together, or abort without committing their changes. MongoDB’s official guidance describes transactions as updating multiple collections in a single atomic operation. Transactions require a replica set or sharded cluster; standalone deployments do not support them. See MongoDB’s transaction guidance and read-isolation documentation.
Consistency: choose what data a read is allowed to return
Consistency is not a single setting that makes every read return the globally latest value. MongoDB’s read concern controls which data a read may return, while write concern controls the acknowledgment requested for a write.
localread concern: may return data that has not been majority committed and could later be rolled back.majorityread concern: returns data acknowledged by a majority of voting members.
In causally consistent client sessions, MongoDB documents that combining majority read concern with majority write concern provides the full set of causal guarantees. That is distinct from a transaction’s atomic commit behavior; it does not mean every default read is causally consistent or globally current. See MongoDB’s read concern, write concern, and default read and write concern documentation.
Free tools Windows power users keep installed
One-click scans. No signup required.
Isolation: snapshot reads have specific conditions
With snapshot read concern, MongoDB returns majority-committed data as it appeared at a single point in time. For a transaction, the snapshot guarantee depends on committing with writeConcern: { w: "majority" }. In a causally consistent session, the snapshot can also be causally consistent with the operation immediately before the transaction began. The guarantee is not an assertion that every reader outside the transaction sees the same snapshot.
In particular, outside reads using local can see part of a committed cross-shard transaction before seeing the rest. For the version-specific details, consult the MongoDB 8.0 snapshot read concern documentation alongside the current read concern reference and read isolation guidance.
Rank #4
Durability: acknowledgment depends on concern, topology, and version
Write concern specifies the acknowledgment a write must receive before MongoDB reports success. The implicit default is majority in ordinary configurations, but MongoDB documents an exception for replica sets with arbiters when the data-bearing voting members do not exceed the voting majority. Check the defaults for your replica-set topology rather than assuming the ordinary default applies.
MongoDB’s defaults documentation says majority acknowledgment waits for on-disk journaling by default, subject to writeConcernMajorityJournalDefault. There is also a version distinction: starting in MongoDB 8.0, a { w: "majority" } write is acknowledged after a majority of data-bearing members durably write the oplog entry. These details are documented in MongoDB’s default concern reference and write concern reference.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →When to use a multi-document transaction
Use a transaction when the application must read or change multiple documents or collections as one logical operation, and partial completion would violate an application invariant. For example, if a workflow must update records in separate collections together, a transaction can make the commit all-or-nothing.
Before adding a transaction, ask whether the related state can be modeled so one atomic document update is sufficient. MongoDB notes that transactions may be less performant than other consistency methods, and open transactions can negatively affect read performance. There is no universal performance penalty to apply to every workload; evaluate the effect under your actual access pattern and deployment. MongoDB discusses these trade-offs in its consistency and transactions guidance and read isolation documentation.
Quick Recap
Quick decision guide
| Question | Single-document design | Multi-document transaction |
|---|---|---|
| How many documents or collections must change together? | Use when the invariant fits within one document. | Use when the invariant spans documents or collections. |
| Must the changes commit all-or-nothing? | A write to one document is atomic. | Changes in the transaction commit or abort together. |
| What deployment is required? | Single-document atomicity applies to document writes. | Replica set or sharded cluster; standalone deployments are unsupported. |
| What read and write guarantees are needed? | Select concerns appropriate to the application’s reads and acknowledgments. | Set transaction concerns to meet the required guarantees; snapshot reads require majority write concern at commit. |
| What about performance? | Can avoid transaction overhead when the data model meets the invariant. | May be less performant; open transactions can affect read performance. Measure for the workload. |
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
