• Release Notes >
  • Release Notes for MongoDB 4.0 Release Candidate

Release Notes for MongoDB 4.0 Release Candidate

MongoDB 4.0 is currently in development.


While 4.0 release candidates are available, these versions of MongoDB are for testing purposes only and not for production use.

Multi-Document Transactions

Starting in version 4.0, MongoDB provides the ability to perform multi-document transactions against replica sets. With multi-document transactions, until a transaction commits, no write operations in the transaction are visible outside the transaction. That is, the multi-document transactions are atomic.


In most cases, multi-document transaction incurs a greater performance cost over single document writes, and the availability of multi-document transaction should not be a replacement for effective schema design. For many scenarios, the denormalized data model (embedded documents and arrays) will continue to be optimal for your data and use cases. That is, for many scenarios, modeling your data appropriately will minimize the need for multi-document transactions.

Feature Compatibility

The featureCompatibilityVersion of all members of the replica set must be 4.0 or greater. To check the featureCompatibilityVersion for a member, connect to the member and run the following command:

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

For more information on the featureCompatibilityVersion flag, see setFeatureCompatibilityVersion.

mongo Shell Methods

Method Description
Session.startTransaction() Starts a multi-statement transaction.
Session.commitTransaction() Commits the transaction.
Session.abortTransaction() Aborts the transaction.

MongoDB Drivers

Clients require MongoDB drivers updated for MongoDB 4.0 to use transactions.

Read Concern snapshot

MongoDB 4.0 introduces a new read concern level "snapshot" for multi-document transaction.

For a multi-document transaction, MongoDB may sometimes substitute a stronger read concern for "local" and "majority" read concern/

For a list of all operations that accept read concerns, see readConcern Support.

Read Preference

Multi-document transactions that contain read operations must use read preference primary.

All operations in a given transaction must route to the same member.



By default, multi-document transactions wait 5 milliseconds to acquire locks required by the operations in the transaction. If the transaction cannot acquire its required locks with the 5 milliseconds, the transaction aborts.

You can use the maxTransactionLockRequestTimeoutMillis parameter to adjust how long transactions wait to acquire locks.

Transactions release all locks upon abort or commit.


The aggregation pipeline stage $currentOp (and the currentOp command and mongo shell helper db.currentOp() method) return information on inactive sessions which are holding locks as part of a transaction.



New Type Conversion Operators

MongoDB 4.0 adds the following new aggregation operators for type conversion:

Operator Description
$convert Convert value to specified type.
$toBool Convert value to boolean.
$toDate Convert value to Date.
$toDecimal Convert value to Decimal128.
$toDouble Convert value to Double.
$toInt Convert value to integer.
$toLong Convert value to long.
$toObjectId Convert value to ObjectId.
$toString Convert value to string.

New String Operators

MongoDB 4.0 adds the following new aggregation string operators:

Operator Description
$ltrim Removes whitespace or the specified characters from the beginning of a string.
$rtrim Removes whitespace or the specified characters from the end of a string.
$trim Removes whitespace or the specified characters from the beginning and end of a string.

Additional Improvements


The $bucket stage no longer requires boundaries document arguments to be wrapped in $literal.


The $dateToString aggregation operator has the following option changes:


Requires featureCompatibilityVersion (fCV) set to "4.0" or greater.

  • A new option onNull specifies the value to return if the date is null or missing.
  • The option format is now optional.


The aggregation pipeline stage $currentOp supports the following new options:

  • idleSessions option to return information on inactive sessions which are holding locks as part of a transaction.
  • localOps option to report operations that are running locally on the current mongos instance, rather than reporting operations that are running on the shards.


Add Support for SCRAM-SHA-256


To use SCRAM-SHA-256, the featureCompatibilityVersion must be set to 4.0. For more information on featureCompatibilityVersion, see View FeatureCompatibilityVersion and setFeatureCompatibilityVersion.

MongoDB adds support for SCRAM authentication mechanism SCRAM-SHA-256, which uses the SHA-256 hash function. To modify the iteration count for SCRAM-SHA-256, MongoDB adds a new parameter scramSHA256IterationCount.

New Option for Create and Update User Operations

When creating or updating a SCRAM user, you can indicate the specific SCRAM mechanism or mechanisms to use for the user credentials. Specifically, MongoDB 4.0 adds the mechanisms option to the following commands and mongo shell helpers:

Command Method
createUser db.createUser()
updateUser db.updateUser()

When using SCRAM-SHA-256, MongoDB (i.e. the server) requires undigested password. Starting in MongoDB 4.0, the default value of digestPassword is true for createUser, and the default value of passwordDigestor is "server". In earlier MongoDB versions, digestPassword is false and client respectively.

New Option for isMaster Command

Starting in MongoDB 4.0, the isMaster command accepts an optional field saslSupportedMechs: <db.user> to return an additional field isMaster.saslSupportedMechs in its result.

isMaster.saslSupportedMechs is an array of SASL mechanisms used to create the specified user’s credentials.

Remove Support for MONGODB-CR

Starting in version 4.0, MongoDB removes support for the deprecated MongoDB Challenge-Response (MONGODB-CR) authentication mechanism.

Since version 3.0, MongoDB has not supported the creation of MONGODB-CR users unless the deployment had been upgraded from a 2.6 or earlier deployment that already had MONGODB-CR users and had not upgraded the authentication schema.

If your deployment has user credentials stored in MONGODB-CR schema, you must upgrade to Salted Challenge Response Authentication Mechanism (SCRAM) before you upgrade to version 4.0. For information on upgrading to SCRAM, see Upgrade to SCRAM.

usersInfo Enhancement

The usersInfo command can return information across all databases by specifying:

{ usersInfo: { forAllDBs: true } }

The usersInfo and the mongo shell helpers db.getUser() and db.getUsers() method accept a new optional filter document. The filter document specifies $match stage conditions to return information only for users that match the conditions.

The usersInfo command and the mongo shell helpers db.getUser() and db.getUsers() method return the mechanisms field for the user.

Disable TLS 1.0

MongoDB binaries (mongod, mongos, and mongo) disables support for TLS 1.0 encryption on systems where TLS 1.1+ is available.

If you need to support TLS 1.0:

On macOS, to connect mongo shell version 3.6.4 or earlier to a MongoDB 4.0+ deployment requires explicit enabling of TLS 1.0.

Deprecate MMAPv1

Starting in version 4.0, MongoDB deprecates the MMAPv1 Storage Engine and will remove MMAPv1 in a future release.

To change your MMAPv1 storage engine deployment to WiredTiger Storage Engine, see:

Replica Set

Remove pv0 for Replica Sets

MongoDB 4.0 removes the deprecated replica set protocol version 0 pv0.

Before upgrading to MongoDB 4.0, you must upgrade to pv1.

To upgrade to pv1, connect a mongo shell to the replica set primary and perform the following sequence of operations:

cfg = rs.conf();

You can use catchUpTimeoutMillis to prioritize between faster failovers and preservation of w:1 writes.

For more information on pv1, see Replica Set Protocol Version.

Remove Master-Slave Replication

MongoDB 4.0 removes support for the deprecated master-slave replication. Before you can upgrade to MongoDB 4.0, if your deployment uses master-slave replication, you must upgrade to a replica set.

To convert your master-slave replication, see Convert a Master-Slave Deployment to a Replica Set.

Journaling and Replica Sets

Starting in MongoDB 4.0, you cannot specify --nojournal option or storage.journal.enabled: false for replica set members that use the WiredTiger storage engine.

rollbackTimeLimitSecs Parameter Available

In MongoDB 4.0, a new rollbackTimeLimitSecs parameter allows for the setting of the time limit in seconds between the common point and the last oplog write entry in a stepped-down primary.

Wait for Background Index Builds

Starting in version 4.0, MongoDB waits for any in-progress background index builds to finish before starting a rollback.

Rollback Files

MongoDB adds the parameter createRollbackDataFiles that determines whether during a rollback, MongoDB creates rollback files that contains documents affected during the rollback.

replSetGetStatus Output Changes

The replSetGetStatus returns the following new fields:

The following fields returned from replSetGetStatus are deprecated:

Platform Support

  • MongoDB 4.0 (Community & Enterprise) adds support for:
  • MongoDB 4.0 (Community) adds support for:
    • s390x RHEL 6.x
  • MongoDB 4.0 does not support SLES 11. Support for SLES 11 has also been removed in MongoDB 3.2.20+, 3.4.15+, and 3.6.4+.
  • MongoDB 4.0 does not support Ubuntu 12.04. Support for Ubuntu 12.04 has also been removed in MongoDB 3.2.20+, 3.4.15+, and 3.6.4+.

Refer to Supported Platforms for the full platform support matrix.

  • MongoDB 4.0 binaries for macOS support TLS 1.2.

General Improvements

Query Operators

  • The geospatial query operators $near and $nearSphere now supports querying on sharded collections.


Network Layer Improvements

Configuration Options


  • The JavaScript engine’s JIT compiler is now disabled by default.
  • Upgraded MozJS to ESR 45.9.0.
  • Added RECOVERY component to log messages.
  • MongoDB 4.0 adds support for using the appName connection string option for setting a custom app name when connecting from the mongo shell. Previously, only MongoDB drivers supported using the appName to set a custom value and the mongo shell used the default MongoDB Shell value as the app name.

Changes Affecting Compatibility

Some changes can affect compatibility and may require user actions. For a detailed list of compatibility changes, see Compatibility Changes in MongoDB 4.0.

Upgrade Procedures

Feature Compatibility Version

To upgrade, the 3.6 instances must have featureCompatibilityVersion set to 3.6. To check the version:

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

For specific details on verifying and setting the featureCompatibilityVersion as well as information on other prerequisites/considerations for upgrades, refer to the individual upgrade instructions:

If you need guidance on upgrading to 4.0, MongoDB offers major version upgrade services to help ensure a smooth transition without interruption to your MongoDB application.

Known Issues in 4.0.0

Report an Issue

To report an issue, see for instructions on how to file a JIRA ticket for the MongoDB server or one of the related projects.