How do transactions work in MongoDB?

Question

Accepted Answer

MongoDB supports **multi-document ACID transactions** (since v4.0 for replica sets, v4.2 for sharded clusters) — grouping operations across multiple documents/collections so they all succeed or all fail. However, MongoDB's document model often makes transactions *unnecessary* through atomic single-document operations.

## Single-document operations are already atomic

```text
KEY POINT: operations on a SINGLE document are ALWAYS atomic in MongoDB.
→ Because related data is often EMBEDDED in one document, many operations that would
  need a transaction in SQL are a single atomic document update in MongoDB.
→ Good schema design (embedding) often eliminates the NEED for multi-doc transactions.
```

```js
// updating a document and its embedded array atomically — NO transaction needed
db.accounts.updateOne(
  { _id: id },
  { $inc: { balance: -100 }, $push: { transactions: { amount: -100 } } }
);  // atomic — both changes succeed or fail together (single document)
```

## Multi-document transactions (when truly needed)

```js
// for operations across MULTIPLE documents/collections that must be atomic
const session = db.getMongo().startSession();
session.startTransaction();
try {
  db.accounts.updateOne({ _id: 1 }, { $inc: { balance: -100 } }, { session });
  db.accounts.updateOne({ _id: 2 }, { $inc: { balance: 100 } }, { session });
  session.commitTransaction();        // both succeed together
} catch (e) {
  session.abortTransaction();          // or both roll back
} finally {
  session.endSession();
}
```

Multi-document transactions (using a session) provide ACID guarantees across documents — for cases like transferring between separate account documents.

## Use transactions sparingly

```text
✓ Transactions are available and provide ACID across documents WHEN NEEDED
✗ But they have PERFORMANCE COSTS (overhead, locking) — don't overuse them
→ PREFER good schema design (embedding related data) so single-document atomic
  operations suffice. Use multi-document transactions only when data genuinely
  spans documents and must be consistent (e.g. money transfers between accounts).
→ Requires a replica set (not standalone).
```

## Why it matters

Understanding MongoDB transactions — and crucially when they're needed — is important for ensuring data consistency in MongoDB applications, so it's valuable knowledge for building correct systems.

The most important insight is that **single-document operations are always atomic** in MongoDB, and because the document model encourages **embedding related data in one document**, many operations that would require a transaction in a relational database (where related data is split across tables) are a **single atomic document update** in MongoDB — so **good schema design often eliminates the need for multi-document transactions**.

This is a key conceptual point: MongoDB's atomicity-per-document, combined with embedding, handles many consistency needs without transactions.

Understanding that MongoDB **does support multi-document ACID transactions** (since v4.0+) for cases where operations genuinely span multiple documents/collections (like transferring between separate account documents) is important — they're available when truly needed, providing all-or-nothing guarantees.

Equally important is the guidance to **use transactions sparingly**: they have performance costs (overhead, locking), so the preferred approach is good schema design (embedding) so single-document atomic operations suffice, reserving multi-document transactions for genuine cross-document consistency needs.

Understanding this — single-document atomicity, that embedding often removes the need for transactions, that multi-document transactions exist for when they're genuinely required, and the preference for design over transactions — reflects sound MongoDB judgment.

Since data consistency is critical and MongoDB's approach (document atomicity + optional transactions) differs from SQL's transaction-centric model, understanding MongoDB transactions — especially that single-document operations are atomic, embedding reduces transaction needs, and multi-document transactions are available but should be used judiciously — is valuable, important knowledge for ensuring consistency correctly and efficiently in MongoDB applications, a topic that reflects understanding of MongoDB's consistency model and good design practices.