Lv.1 IntroPostgreSQL / MongoDB

2026.05.2513 min readLv.1 Intro

SeriesTransactions in PostgreSQL and MongoDB: What's the Difference? · Part 1View series hub

What Is a Transaction? Comparing ACID in PostgreSQL and MongoDB — Part 1

A transaction is more than a bundle of queries. PostgreSQL wraps every single statement in an implicit transaction, while MongoDB added explicit multi-document ACID support starting from version 4.0. This post walks through the four ACID properties — Atomicity, Consistency, Isolation, and Durability — and shows how each database implements them differently, with BEGIN/COMMIT examples and session-based transaction code.

Series — Transactions in PostgreSQL and MongoDB: What's the Difference?

• Part 1 — Transaction Fundamentals and ACID Principles (current)
• Part 2 — Deep Dive: PostgreSQL Transactions (Isolation Levels, MVCC)
• Part 3 — MongoDB Transaction Evolution and Multi-Document Transactions
• Part 4 — Real-world Comparison — Performance, Scalability, and Which DB Should You Choose?

Table of Contents

1. Introduction — Why Transactions Matter
2. What Is a Transaction?
3. ACID: The Four Principles of Transactions
   • 3-1. Atomicity
   • 3-2. Consistency
   • 3-3. Isolation
   • 3-4. Durability
4. PostgreSQL vs MongoDB — How They Implement ACID
5. Where Both Databases Stand in 2026
6. Part 1 Summary
7. Practical application notes

1. Introduction — Why Transactions Matter

The era of "databases means MySQL" is over. In 2026, the two most widely used databases among developers are PostgreSQL and MongoDB.

According to the Stack Overflow Developer Survey 2025, approximately 55.6% of developers use PostgreSQL, while MongoDB follows at roughly 24%. Both have evolved dramatically over the years, making it increasingly difficult to separate them with a simple "relational vs. non-relational" label.

At the center of that evolution is transactions.

When MongoDB first appeared, many developers were told "MongoDB doesn't support transactions." Today, that statement is completely outdated. Understanding the transaction philosophy and implementation of each database is essential to making sound architectural decisions.

2. What Is a Transaction?

A transaction is a logical unit of work in a database — a group of operations treated as a single whole.

The classic example is a bank transfer:

1. Deduct $1,000 from account A
2. Add $1,000 to account B

What happens if step 1 succeeds but step 2 fails? The money disappears. Transactions prevent this by guaranteeing "All or Nothing" — either every operation succeeds, or none of them take effect.

-- PostgreSQL transaction example
BEGIN;

UPDATE accounts SET balance = balance - 1000 WHERE id = 'A';
UPDATE accounts SET balance = balance + 1000 WHERE id = 'B';

COMMIT;   -- commit when all succeed
-- ROLLBACK;  -- roll back everything if any step fails

The diagram below shows how a transaction branches:

3. ACID: The Four Principles of Transactions

For a transaction to behave correctly, it must satisfy ACID — four properties that form the foundation of database reliability.

3-1. Atomicity

"All operations in a transaction must either fully succeed or not execute at all."

Atomicity treats a transaction as an indivisible unit. No intermediate state can exist.

• All operations succeed → COMMIT (changes are permanently applied)
• Any single operation fails → ROLLBACK (all changes are discarded)

3-2. Consistency

"After a transaction completes, the database must remain in a consistent state."

If a constraint says account balances cannot go negative, that rule must hold before and after every transaction. Consistency ensures that developer-defined business rules and integrity constraints are always respected.

3-3. Isolation

"Concurrent transactions must not interfere with each other."

In production, thousands of transactions run simultaneously. Isolation ensures each transaction behaves as if it is the only one running.

Isolation levels control the trade-off between performance and consistency.

PostgreSQL's MVCC (Multi-Version Concurrency Control) and the behavior of each isolation level are covered in detail in Part 2.

3-4. Durability

"The effects of a committed transaction must persist even if the system crashes."

Even if the server goes down unexpectedly, data that has already been committed cannot be lost. PostgreSQL implements this with WAL (Write-Ahead Log); MongoDB uses journaling through the WiredTiger storage engine.

4. PostgreSQL vs MongoDB — How They Implement ACID

Both databases support ACID, but their philosophies and scopes differ significantly.

PostgreSQL's ACID

PostgreSQL was designed from the ground up around ACID. Every single statement is processed as a transaction. Even an UPDATE without an explicit BEGIN is automatically wrapped in an implicit transaction (Auto-commit).

-- Explicit transaction
BEGIN;
  INSERT INTO orders (user_id, amount) VALUES (1, 500);
  UPDATE inventory SET stock = stock - 1 WHERE product_id = 42;
COMMIT;

-- Implicit transaction — a single statement is already atomic
DELETE FROM sessions WHERE expired_at < NOW();

PostgreSQL provides full ACID guarantees by default — no additional configuration required.

MongoDB's ACID — A History of Evolution

MongoDB originally guaranteed atomicity only at the single-document level. Modifications to fields within a single document were atomic, but operations spanning multiple documents or collections were not.

Early MongoDB (before 4.0):
- Atomicity guaranteed only at the single-document level
- Transactions across multiple collections: not supported

After adopting the WiredTiger storage engine, MongoDB 4.0 (2018) introduced multi-document ACID transactions. MongoDB 4.2 extended that support to sharded clusters with distributed transactions.

// MongoDB multi-document transaction example
const session = client.startSession();
session.startTransaction();

try {
  await accounts.updateOne(
    { _id: 'A' },
    { $inc: { balance: -1000 } },
    { session }
  );
  await accounts.updateOne(
    { _id: 'B' },
    { $inc: { balance: 1000 } },
    { session }
  );
  await session.commitTransaction();
} catch (error) {
  await session.abortTransaction();
} finally {
  session.endSession();
}

The key distinction: PostgreSQL treats ACID as the default and applies it automatically to every operation. MongoDB guarantees atomicity on single-document operations by default, but multi-document transactions require explicitly opening and managing a session.

5. Where Both Databases Stand in 2026

As of the 2026 DB-Engines ranking, PostgreSQL sits at 4th place and MongoDB at 5th. The two databases are converging in an interesting pattern.

• PostgreSQL: Expanding into NoSQL territory with enhanced JSONB, vector search (pgvector), and improved partitioning
• MongoDB: Establishing enterprise credibility with multi-document ACID transactions, Atlas Vector Search 2.1, and Queryable Encryption 2.0

The boundary between the two databases is blurring, but differences in core philosophy and transaction handling remain a meaningful factor in architectural decisions.

6. Part 1 Summary

This part covered the fundamentals of transactions, the four ACID properties, and how PostgreSQL and MongoDB take different approaches to each.

Key takeaways:

• Transaction = the smallest logical unit of work, All or Nothing
• ACID = Atomicity / Consistency / Isolation / Durability
• PostgreSQL = full ACID by default, every statement is automatically a transaction
• MongoDB = single-document atomicity by default; multi-document transactions available from version 4.0 with an explicit session

Part 2 takes a deeper look at PostgreSQL transactions — covering MVCC, the behavior of each isolation level, and how to handle deadlocks in production.

References

• Bytebase: Postgres vs. MongoDB (2025)
• tech-insider.org: MongoDB vs PostgreSQL 2026
• DEV Community: PostgreSQL vs MongoDB in 2025
• leanware.co: MongoDB vs PostgreSQL
• hoing.io: MongoDB Transaction Isolation Levels