Should You Enable MongoDB® Journaling?

2 min read
Should You Enable MongoDB® Journaling?


MongoDB® uses an on-disk journal to guarantee write operations and provide crash resiliency. MongoDB also creates a journal for every write that includes the exact disk location and the bytes that changed in the write. Thus, if you have a crash in the server, the journal can be used to replay any writes that have not yet been written to the data files.

MongoDB uses memory mapped files to write your data to disk. By default, MongoDB data files are flushed to disk every 60 seconds. They also uses memory mapped files for the journal, and by default, the journal is flushed to disk every 100ms. Since the final data files are flushed to disk every 60 seconds, the journal does not need to track writes for more than one minute. For more details on the mechanics of the journaling, refer to the official documentation. To understand how the view mapping works in more detail, you can check out Kristina’s blog.

Journaling Write Concern

> db.runCommand({"getLastError":1, "j":true});

When you turn on MongoDB journaling, you also have the ability to specify a write concern in MongoDB of ‘Journaled’ for your MongoDB operations. This implies that MongoDB confirms the write operation only after committing to the journal.  However, this has a drawback – when you specify “j”:true with getLastError, MongoDB will wait for about 1/3 of the journal commit internal before committing the journal data. The default journal commit interval is 100ms – so MongoDB will wait 30ms and commit the data. This essentially means that on a single thread, you can only get about 33.3 writes/second, and the recommended best practice is to batch your writes. For example, if you have 50 writes, use the “j”:true setting only on the last write – this will acknowledge that all the previous 50 writes are done.


Every production MongoDB instance should run with journaling enabled. If you don’t have journaling enabled and your server or MongoDB process crashes, MongoDB will not be able to ensure data integrity. You’ll need to run a “repair” operation on the database, which, depending on the amount of data, could take a few hours to complete. Turn it off only if you really know what you’re doing. At ScaleGrid, all our instances follow the MongoDB best practice configuration and have journaling turned on by default.

Also read:
MongoDB Storage Engines

For more information, please visit Connect with ScaleGrid on LinkedIn, X, Facebook, and YouTube.
Table of Contents

Stay Ahead with ScaleGrid Insights

Dive into the world of database management with our monthly newsletter. Get expert tips, in-depth articles, and the latest news, directly to your inbox.

Related Posts

high available cluster

High Availability Clustering & Why You Need It

High availability clustering keeps your IT systems running without interruptions, even amid failures. This guide details high availability clustering, its...


What’s New at ScaleGrid – July 2024

ScaleGrid is excited to announce our latest platform updates, showcasing our unwavering commitment to security, usability, and performance. Our recent...

database backend

What is RabbitMQ Used For

RabbitMQ is an open-source message broker facilitating the connection between different applications within a distributed setup. It is widely utilized...


Add Headline Here