Emmanuel Olusola

Posted on Jan 27

MongoDB Transactions Are Not What You Think

Or: why half the MongoDB transactions you see in Node.js backends are quietly fixing bad schema design.

MongoDB transactions are one of those features that sound reassuring.

They whisper:

“Relax. You can build this just like Postgres.”

And for a lot of Node.js developers, especially those coming from SQL-heavy stacks, that whisper is seductive.

But here’s the uncomfortable truth:

MongoDB transactions are not a default tool. They are an escape hatch.

Used sparingly, they’re fine. Used casually, they slowly drain performance, complicate your Node.js code, and hide deeper modeling problems.

Let’s talk about when not to use them, why they’re expensive, and how most MongoDB transactions exist only because we refused to model our data properly.

The Context: Why MongoDB Even Added Transactions

MongoDB was built around a very specific idea:

Model data the way your application uses it.

That meant:

Embed related data
Accept duplication
Optimize for reads and writes your app actually performs
Rely on single-document atomicity

For years, MongoDB held this line.

Then enterprise migrations happened.

Large teams moving from Oracle, MySQL, and Postgres kept asking:

“How do I update multiple tables atomically?”

MongoDB eventually added multi-document transactions in v4.0.

Not because MongoDB needed them, but because people refused to let go of relational thinking.

That distinction matters.

The First Myth: “MongoDB Transactions Work Like SQL Transactions”

Yes, MongoDB transactions are ACID.
Yes, they support rollback.
Yes, they span collections.

But the similarity ends at the API surface.

In relational databases:

Transactions are the foundation
Storage engines are optimized around them
Locking, logging, and rollback are first-class

In MongoDB:

Transactions sit on top of a document database
They introduce coordination MongoDB usually avoids
They work against MongoDB’s natural performance model

Treating MongoDB like a relational database with JSON columns is how you get slow Node.js APIs and mysterious latency spikes.

The Node.js Anti‑Pattern: “Just Wrap It in a Transaction”

You’ll see code like this everywhere:

const session = await mongoose.startSession();
session.startTransaction();

try {
  await Orders.updateOne({ _id }, { status: 'PAID' }, { session });
  await Payments.insertOne(payment, { session });
  await Shipments.insertOne(shipment, { session });

  await session.commitTransaction();
} catch (err) {
  await session.abortTransaction();
  throw err;
}

Looks responsible. Feels safe.

But ask the real question:

Why do these writes need to be in three collections?

Most MongoDB Transactions Exist to Fix Bad Schema Design

In MongoDB, this is a smell:

orders
payments
shipments
order_items

All tightly coupled.
All always updated together.

That’s not “normalization”.
That’s fragmentation.

The MongoDB-Native Model

MongoDB wants this:

{
  "_id": "order_123",
  "status": "PAID",
  "items": [...],
  "payment": {
    "method": "card",
    "amount": 5000
  },
  "shipment": {
    "carrier": "DHL",
    "status": "PENDING"
  }
}

Now your Node.js write becomes:

await Orders.updateOne(
  { _id: orderId },
  {
    $set: {
      status: 'PAID',
      payment,
      shipment
    }
  }
);

One document.
One atomic operation.
No transaction.
No coordination overhead.

Performance Costs (The Part People Discover in Production)

MongoDB transactions are not free.

1. Longer-Lived Locks

Documents touched in a transaction remain “in flux” longer.

Under Node.js concurrency, this means:

More waiting
Higher p99 latency
Weird spikes you can’t reproduce locally

2. Replication Lag

Transactions replicate as a unit.

Large or frequent transactions mean:

Bigger oplog entries
Slower secondaries
Risky failovers

3. Automatic Retries Multiply Load

MongoDB retries transactions automatically.

So your single API call might:

Execute twice
Lock twice
Write twice

Your Node.js metrics say traffic is stable.
Your database knows the truth.

The Consistency Anxiety Trap

A lot of Node.js developers use transactions because of fear:

“What if something fails halfway?”

But here’s the reality:

Most systems don’t need perfect consistency. They need recoverability.

MongoDB already supports:

idempotent writes
retryable writes
compensating updates

Example:

await Orders.updateOne(
  { _id: orderId, status: { $ne: 'PAID' } },
  { $set: { status: 'PAID' } }
);

Safe.
Retryable.
No transaction.

When MongoDB Transactions Actually Make Sense

Transactions are not evil. They’re just specialized.

Use them when:

✅ Independent Aggregates

Wallet-to-wallet transfers
Inventory movement between warehouses

✅ Rare Administrative Work

Migrations
Data repair scripts
Back-office workflows

✅ True Cross-Boundary Guarantees

When embedding or denormalization is genuinely impossible.

If transactions dominate your request handlers, your schema is trying to tell you something.

A Better Mental Model for Node.js + MongoDB

Documents are mini-databases
Atomicity is a design choice, not a feature toggle
Consistency is earned through modeling

Ask instead:

What must be consistent now?
What can be eventually consistent?
What can be recovered instead of rolled back?

Your Node.js code gets:

simpler
faster
easier to reason about

Finally

MongoDB transactions are like painkillers.

Useful.
Necessary sometimes.

But if your Node.js backend depends on them daily?

You’re not solving the problem.
You’re numbing it.

Well-designed MongoDB systems rarely need transactions.

And when they do, everyone knows exactly why.

DEV Community