Default Majority Write Concern: Providing Stronger Durability Guarantees "Out of the Box"

MongoDB has always provided developers with the flexibility to control the desired levels of write durability, enabling them to balance latency and throughput against the application’s SLAs. The chosen write concern dictates how many nodes in the MongoDB database cluster need to acknowledge the write before success is passed back to the application. You can configure the write concern either in the driver or via a cluster-wide, global setting in the server.

Prior to the 5.0 release, MongoDB defaulted to the w:1 write concern, which waits for the write to be applied to memory on the primary node before acknowledging success back to the application. This default was adequate to meet the durability requirements of the most common applications built on MongoDB. Over the past several years, this application profile has extended as the MongoDB database has evolved, especially in serving more mission-critical, transactional applications. At the same time, we have made replication faster – so enforcing data durability across multiple nodes in a distributed database cluster no longer imposes the performance trade-offs of the past.

It is for these reasons that starting with MongoDB 5.0, the default durability guarantee has been elevated to the majority (w:majority) write concern. This means that write success will now only be acknowledged to the application once it has been committed and persisted to disk on a majority of replicas.

Choosing the new default vs. the former w:1 default allows for a stronger durability guarantee where acknowledged data can survive replica set elections and complete node failures. The new w:majority default setting is fully tunable, so you can maintain the earlier w:1 default or any custom write concern you had previously configured.

In this blog post, I will dig into why we have made the decision to move to w:majority as the new default, and explain how it works as you upgrade your existing MongoDB cluster and deploy a new MongoDB environment.

w:1 to w:majority default concern: A decision rooted in key MongoDB milestones

The decision of making w:majority the default “out of the box” write concern is deeply rooted in our technology evolution and the experience that comes from the increased sophistication of our user’s workloads.

With the release of MongoDB 4.0 (June 2018), we added support for multi-document ACID transactions. This made it extremely easy for developers to address a complete new range of modern systems of record applications with MongoDB. Transactional guarantees were initially scoped to replica sets and then extended 12 months later to sharded clusters with the MongoDB 4.2 release.

In May 2019, the MongoDB Atlas default connection string used by the drivers to connect to the database was changed to w:majority. This effectively eliminated any manual tuning by Atlas users who required a higher level of durability guarantees. It also enabled us to evaluate whether users maintained those stronger guarantees, or dialed them down to the w: 1 primary acknowledged concern. The vast majority of users stuck with the stronger write concern.

In MongoDB 4.4 (June 2020), we radically improved replication performance with the introduction of streaming replication and “replicate-before-journaling”. Rather than replicas polling the primary and receiving batches of events to apply locally, streaming replication allows the primary to continuously stream messages to the replicas. Coupled with replicate-before-journaling, which allows secondary nodes to read a primary node's oplog entries prior to them being locally journaled, these changes see the latency of majority committed writes reduced by up to 50% over high load networks.

Throughout the years our product and engineering teams have studied the benefits of all these innovations and specifically of w:majority to our user base. One fundamental principle of w:majority is that the time taken to perform writes server-side does not really change. The added time it takes for the driver to acknowledge the write operation on the client-side strengthens the durability the application can expect for each write and improves the overall health and performance of the MongoDB cluster.

This new MongoDB 5.0 w:majority default is just a reflection of how users have extended their utilization of MongoDB to modernize mission-critical applications.

Upgrade considerations

For users who do not set any write concern and instead rely on the defaults that MongoDB provides, w:majority will become the default write concern starting in MongoDB 5.0. This new default will take effect without any user action.

The new default does not override any explicit write concerns that developers have configured previously. Developers who want their application to continue to use the write concern w:1 should explicitly set their default write concern to w:1 prior to upgrade, whether in their driver or server-side with a global write concern to maintain the previous behavior.

Special considerations for MongoDB clusters with arbiters

First, we should remind users that as a general practice we recommend against using arbiters in production clusters.

For MongoDB clusters that do use arbiters, if the loss of a single data holding node would leave majority writes unable to succeed, then MongoDB 5.0 defaults the write concern to w:1, otherwise, it defaults to w:majority. This translates to a default write concern of w:1 for primary-secondary-arbiter (PSA) configurations, but a default write concern of w:majority for cluster configurations like PSSSA. This prevents users with configurations like PSA from experiencing write unavailability in cases where one data-bearing node is unavailable.

Latency and throughput

When comparing latency and throughput of w:1 and w:majority there are many application and environment-specific factors that will determine impacts to performance.

• With the replication enhancements delivered in MongoDB 4.4, users upgrading from earlier MongoDB releases will see little to no latency impact of the higher durability guarantees in MongoDB 5.0.
• Ensuring you have sufficient client concurrency should yield little to no impact on overall throughput.

We will go over those factors and share the results of our performance tests in a future blog post, however, the best way to evaluate latency and throughput of different write concerns is to test in your own environment.

Getting started with MongoDB 5.0

We encourage all MongoDB users to evaluate our new 5.0 release to experience the benefits of the new w:majority default and everything MongoDB 5.0 offers.