1. What Is a Checkpoint?

If you are an Oracle DBA, you already know checkpoints well. In Oracle, a checkpoint is the event where DBWR writes all dirty blocks from the buffer cache to the datafiles on disk. After the checkpoint, the redo logs before that point are no longer needed for instance recovery.

In MongoDB, the concept is the same but the implementation is different. The storage engine WiredTiger performs checkpoints to write all dirty pages from the WiredTiger cache (in memory) to the .wt data files (on disk).

Simple definition:

A checkpoint is a point-in-time snapshot of all data in memory being flushed to disk. After a successful checkpoint, the journal entries before that point can be safely removed.

When does a checkpoint happen?

2. Overall Flowchart

This flowchart shows the complete lifecycle of a checkpoint — from the moment it is triggered to the moment old journal files are cleaned up.

+==============================================================+
║                  CHECKPOINT LIFECYCLE                        ║
+==============================================================+

+----------------------------------------------+
| 1. CHECKPOINT TRIGGERED                      |
|    - Timer: 60 seconds elapsed (default)     |
|    - Size: journal reached 2 GB              |
|    - Manual: fsync command                   |
|    - Shutdown: clean shutdown                |
+-----------------------+----------------------+
                        |
                        v
+----------------------------------------------+
| 2. ACQUIRE CHECKPOINT LOCK                   |
|    WiredTiger takes an exclusive lock on     |
|    the checkpoint process.                   |
|    Normal reads and writes CONTINUE.         |
|    (This is NOT a database-wide lock.)       |
+-----------------------+----------------------+
                        |
                        v
+----------------------------------------------+
| 3. OPEN A NEW SNAPSHOT                       |
|    WiredTiger opens a consistent MVCC        |
|    snapshot of ALL B-trees at this moment.   |
|    This snapshot is the "checkpoint view."   |
|    New writes after this point are NOT       |
|    included in this checkpoint.              |
+-----------------------+----------------------+
                        |
                        v
+----------------------------------------------+
| 4. WALK ALL B-TREES                          |
|    WiredTiger iterates through every         |
|    collection B-tree and every index B-tree. |
|                                              |
|    For each B-tree:                          |
|      - Find all dirty pages in the cache     |
|      - Write dirty pages to the .wt file     |
|        on disk                               |
|      - Pages are compressed before writing   |
|        (Snappy by default)                   |
+-----------------------+----------------------+
                        |
                        v
+----------------------------------------------+
| 5. WRITE INTERNAL METADATA                   |
|    Update the WiredTiger metadata:           |
|      - Root page locations for each B-tree   |
|      - Transaction ID of the checkpoint      |
|      - Timestamp of the checkpoint           |
|    This metadata is written to:              |
|      - WiredTiger.wt (main metadata)         |
|      - WiredTiger.turtle (checkpoint info)   |
+-----------------------+----------------------+
                        |
                        v
+----------------------------------------------+
| 6. FSYNC (FLUSH TO DISK)                     |
|    Force the OS to flush all buffered        |
|    writes to physical disk.                  |
|    This guarantees the checkpoint is         |
|    durable even if the OS crashes.           |
+-----------------------+----------------------+
                        |
                        v
+----------------------------------------------+
| 7. RELEASE CHECKPOINT LOCK                   |
|    The checkpoint is now complete.           |
|    The checkpoint snapshot is closed.        |
+-----------------------+----------------------+
                        |
                        v
+----------------------------------------------+
| 8. JOURNAL CLEANUP                           |
|    All journal entries BEFORE this           |
|    checkpoint are no longer needed.          |
|    Old WiredTigerLog.xxx files are           |
|    deleted from the journal/ directory.      |
+-----------------------+----------------------+
                        |
                        v
+----------------------------------------------+
| 9. WAIT FOR NEXT TRIGGER                     |
|    Timer resets to 60 seconds.               |
|    The cycle repeats.                        |
+----------------------------------------------+

Key point for Oracle DBAs: In Oracle, a checkpoint can cause a “freeze” if DBWR cannot write dirty blocks fast enough (the famous log file sync and free buffer waits events). In MongoDB, the checkpoint runs in the background and does not block normal reads and writes. The checkpoint lock only prevents two checkpoints from running at the same time.

3. Step-by-Step Explanation

Step 1 — Checkpoint is triggered
The most common trigger is the timer. WiredTiger has an internal thread (the checkpoint server thread) that wakes up every 60 seconds (by default) and starts a new checkpoint. Other triggers include the journal reaching 2 GB, a manual fsync command, or a clean shutdown of mongod.

Step 2 — Acquire the checkpoint lock
WiredTiger acquires an internal lock to ensure only one checkpoint runs at a time. This lock does not block user operations. Reads and writes continue normally. This is different from Oracle’s ALTER SYSTEM CHECKPOINT, which can cause a brief spike in I/O as DBWR flushes many blocks at once.

Step 3 — Open a consistent snapshot
WiredTiger opens a new MVCC snapshot. This snapshot captures the state of all data at this exact moment. Any writes that happen after this snapshot is opened will not be part of this checkpoint. They will be captured by the next checkpoint. This is similar to Oracle’s consistent read mechanism — the checkpoint sees a point-in-time view of the data.

Step 4 — Walk all B-trees and write dirty pages
This is the most I/O-intensive step. WiredTiger walks through every B-tree in the database:

• Collection B-trees: Each collection has one or more B-trees that store the documents. WiredTiger finds all pages in the cache that have been modified (dirty) since the last checkpoint and writes them to the corresponding .wt file on disk.
• Index B-trees: Each index has its own B-tree. Dirty index pages are also written to their .wt files.
• Compression: Before writing to disk, pages are compressed using the configured algorithm (Snappy by default). This reduces I/O and disk space.

How many pages are written? Only the pages that have changed since the last checkpoint. If your database had 10,000 inserts in the last 60 seconds, only the pages containing those inserts (and their index entries) are written. Unchanged pages are skipped. This is similar to Oracle’s incremental checkpoint, where DBWR only writes dirty blocks.

Step 5 — Write internal metadata
After all dirty pages are written, WiredTiger updates its internal metadata. This includes:

• The root page location for each B-tree (so WiredTiger knows where to start reading on recovery).
• The transaction ID and timestamp of the checkpoint.
• The list of all B-trees and their file identifiers.

This metadata is written to two files:

• WiredTiger.wt: The main metadata file (like Oracle’s control file). It contains the catalog of all databases, collections, and indexes.
• WiredTiger.turtle: A small file that records the location and timestamp of the last successful checkpoint. On crash recovery, WiredTiger reads this file first to find where to start replaying the journal.

Step 6 — fsync (flush to physical disk)
WiredTiger calls the OS fsync() system call to force all buffered writes to physical disk. This is critical for durability. Without the fsync, the OS might keep the data in its own filesystem cache, and a power failure could lose the checkpoint even though WiredTiger thinks it was written. This is similar to Oracle’s LGWR flushing the redo buffer to the redo log files on disk.

Step 7 — Release the checkpoint lock
The checkpoint is now complete and durable. The lock is released, and the checkpoint server thread goes back to sleep until the next trigger.

Step 8 — Journal cleanup
Now that all data up to the checkpoint is safely on disk, the journal entries before the checkpoint are no longer needed for crash recovery. WiredTiger deletes the old WiredTigerLog.xxx files from the journal/ directory. This keeps the journal directory from growing indefinitely. In Oracle, this is similar to archiving and then deleting old redo logs after a backup.

Step 9 — Wait for the next trigger
The timer resets, and the cycle repeats after 60 seconds (or sooner if the journal reaches 2 GB).

4. Checkpoint and Journal Relationship

The checkpoint and the journal work together to provide durability (the “D” in ACID). Here is how they interact:

TIMELINE (each column = 10 seconds)
──────────────────────────────────────────────────────────────▶

t=0s        t=10s       t=20s       t=30s       t=40s       t=50s       t=60s
 |           |           |           |           |           |           |
 |  INSERT   |  UPDATE   |  DELETE   |  INSERT   |  UPDATE   |  INSERT   |
 |  doc A    |  doc B    |  doc C    |  doc D    |  doc E    |  doc F    |
 |           |           |           |           |           |           |
 |  Journal: |  Journal: |  Journal: |  Journal: |  Journal: |  Journal: |
 |  write A  |  write B  |  write C  |  write D  |  write E  |  write F  |
 |  (100ms)  |  (100ms)  |  (100ms)  |  (100ms)  |  (100ms)  |  (100ms)  |
 |           |           |           |           |           |           |
 |           |           |           |           |           |           |
 |           |           |           |           |           |    ║      |
 |           |           |           |           |           |    ║      |
 |           |           |           |           |           | CHECKPOINT|
 |           |           |           |           |           |  writes   |
 |           |           |           |           |           |  A-F to   |
 |           |           |           |           |           |  .wt files|
 |           |           |           |           |           |    ║      |
 |           |           |           |           |           |    ║      |
 |           |           |           |           |           |  Journal  |
 |           |           |           |           |           |  cleanup: |
 |           |           |           |           |           |  delete   |
 |           |           |           |           |           |  logs for |
 |           |           |           |           |           |  A-F      |

KEY:
  Journal writes happen every 100 ms (fast, sequential I/O)
  Checkpoint happens every 60 seconds (slower, random I/O)
  After checkpoint, old journal files are deleted

The two-layer protection model:

What happens if mongod crashes at different points?

The 100 ms window of vulnerability: With the default write concern (w: 1), MongoDB acknowledges the write as soon as it is in the WiredTiger cache, but the journal may not be flushed to disk for up to 100 ms. If the server crashes during this 100 ms window, the write is lost. To eliminate this window, use j: true in the write concern, which forces an immediate journal flush (like Oracle’s COMMIT which always flushes redo).

5. Crash Recovery Using Checkpoints

Think of a checkpoint as a safe starting point for recovery. If mongod stops unexpectedly, WiredTiger starts from the last completed checkpoint and uses the durable journal records needed to recover later changes.

+---------------------------------------------+
| mongod restarts after an unexpected stop    |
+----------------------+----------------------+
                       |
                       v
+---------------------------------------------+
| Find the last COMPLETED checkpoint          |
| Incomplete checkpoints are not used         |
+----------------------+----------------------+
                       |
                       v
+---------------------------------------------+
| Read the checkpoint data from .wt files     |
+----------------------+----------------------+
                       |
                       v
+---------------------------------------------+
| Are there durable journal records needed    |
| after that checkpoint?                      |
+-------------+--------------------+----------+
              | YES                | NO
              v                    v
+------------------------+  +------------------+
| Replay the necessary   |  | No further       |
| journal records        |  | journal replay   |
+-----------+------------+  +--------+---------+
            |                        |
            +-----------+------------+
                        |
                        v
+---------------------------------------------+
| Recovery completes; mongod can serve data   |
+---------------------------------------------+

Example: Suppose a checkpoint completes at 10:00:00. A document is inserted at 10:00:20, and its journal record is flushed to disk. If the server crashes at 10:00:30, WiredTiger can recover that insert from the journal, even though the next checkpoint has not happened yet.

Oracle DBA comparison: The completed WiredTiger checkpoint is similar to a recovery starting point in Oracle. MongoDB’s journal is broadly comparable to Oracle redo for local crash recovery. MongoDB’s oplog is different: it is used for replica-set replication, not as a replacement for the journal.

Remember: Checkpoints and journals help recover from an unexpected process or server stop. They are not backups and do not protect you from every problem, such as accidentally dropping a collection or losing the storage device.

6. Configuration and Monitoring

For most installations, you should leave the checkpoint settings at their defaults. As an Oracle DBA, your main job is to monitor checkpoint activity and disk performance, not to run checkpoints manually.

Checkpoint interval: WiredTiger normally creates a checkpoint about every 60 seconds. A checkpoint can also occur earlier after approximately 2 GB of journal data has been written. The checkpoint interval is associated with the storage.syncPeriodSecs setting.

# mongod.conf — shown for reference.
# Usually, leave the default unchanged.
storage:
  syncPeriodSecs: 60

Do not use db.fsyncLock() as a routine checkpoint command. It is intended for coordinating certain backup procedures and prevents writes until the lock is released.

Check checkpoint statistics:

// Run against mongod with sufficient monitoring privileges.
const wt = db.serverStatus().wiredTiger;

// WiredTiger transaction statistics include checkpoint metrics.
printjson(wt.transaction);

// Show only fields with "checkpoint" in their names.
// Exact field names vary by MongoDB version.
printjson(
  Object.fromEntries(
    Object.entries(wt.transaction)
      .filter(([name]) => name.includes("checkpoint"))
  )
);

Depending on your MongoDB version, useful fields may include:

• transaction checkpoints — how many checkpoints have completed.
• transaction checkpoint most recent time (msecs) — how long the latest checkpoint took.
• transaction checkpoint currently running — whether a checkpoint is currently active.

Check related cache and journal activity:

// Dirty data waiting in the WiredTiger cache
printjson(db.serverStatus().wiredTiger.cache);

// Journal-related statistics
printjson(db.serverStatus().wiredTiger.log);

// Find configured startup options, if available
printjson(db.adminCommand({ getCmdLineOpts: 1 }).parsed.storage);

At the operating-system level, also monitor free space and disk latency for the volume containing storage.dbPath. For example, on Linux:

df -h /var/lib/mongodb

# Replace /var/lib/mongodb if your dbPath is different.

When should you investigate? If checkpoint duration keeps rising, disk latency is high, or the WiredTiger cache remains under pressure, review the workload and storage performance. A checkpoint normally runs in the background, but heavy checkpoint I/O can still compete with application I/O.

7. Oracle Comparison Table

These are conceptual comparisons, not exact one-to-one matches:

Easy way to remember: Cache holds recent changes; the journal helps recover durable changes after a crash; checkpoints put a consistent recovery point into the data files. The oplog has a different job: replication.