What Is New in MongoDB 4.0
MongoDB 4.0 is a major release that introduced significant enhancements in transactions, sharding, and tooling. It marks a pivotal step towards unifying the developer experience across the entire database.
| Category | Key Changes |
|---|---|
| Multi-Document ACID Transactions | Support for transactions across multiple documents, collections, and databases. |
| Sharding Improvements | Refreshed sharded cluster metadata, faster balancer, and default sharding on UUIDs. |
| Aggregation & Query Enhancements | New operators like $toDouble, $convert, and support for type expressions in $type. |
| Security | Audit log filtering by user and role, and SCRAM-SHA-256 for enhanced authentication. |
| Tooling & Ops | MongoDB Shell (mongosh) improvements, new mongod parameters, and enhanced mongodump output. |
How do transactions work in MongoDB 4.0?
MongoDB 4.0 delivers full multi-document ACID transactions. This is the headline feature that allows you to perform complex operations with atomicity guarantees across your entire dataset.
In practice, you can now wrap operations on multiple documents, even across different collections and databases, within a single transaction. The syntax is familiar, using session.startTransaction(), session.commitTransaction(), and session.abortTransaction(). This matters because it brings MongoDB's consistency model in line with traditional relational databases for complex workflows.
Code Example
const session = db.getMongo().startSession();
session.startTransaction();
try {
db.accounts.updateOne( { _id: 1 }, { $inc: { balance: -100 } }, { session } );
db.accounts.updateOne( { _id: 2 }, { $inc: { balance: 100 } }, { session } );
session.commitTransaction();
} catch (error) {
session.abortTransaction();
}
session.endSession();
What sharding improvements were made?
Sharding got a major performance and reliability overhaul. The balancer is now more efficient, and the config server metadata management was completely refreshed.
A key change is the new way sharded clusters track metadata. Instead of a single source of truth, the config servers now act as a replica set, which simplifies failover and improves consistency. The balancer also got smarter, making chunk migrations faster and less intrusive on cluster performance.
For developers, a subtle but important change is that new collections shard on UUIDs (_id) by default instead of ObjectIds. This prevents potential hotspots on inserts when using monotonically increasing shard keys.
What new aggregation features are available?
The aggregation framework received powerful new type conversion and expression operators. This makes data transformation pipelines more robust and flexible.
The new $convert operator and its helper aliases like $toDouble or $toString allow you to handle type casting directly within your aggregation stages. You can specify on-error and on-null behavior, which is crucial for cleaning up messy data. The $type operator was also enhanced to return the BSON type directly as a string within an expression.
Code Example
// Convert a field to a double, handling errors
db.sales.aggregate([
{
$project: {
price: { $toDouble: "$priceString" },
quantity: { $convert: {
input: "$qty",
to: "int",
onError: 0,
onNull: 0
}}
}
}
])
Were there any security enhancements?
Yes, security was tightened with more granular audit logging and a stronger default authentication mechanism.
You can now filter the audit log output by specific users or roles, which makes it much easier to track actions for compliance without being overwhelmed by noise. Additionally, while SCRAM-SHA-1 is still supported, SCRAM-SHA-256 became available, offering a more secure hashing algorithm for password storage.
FAQ
Are transactions in MongoDB 4.0 exactly like in SQL databases?
They provide the same ACID guarantees but are implemented with a timeout (default 60 seconds) to prevent long-running operations from impacting performance. You must design your application logic with this timeout in mind.
Do I have to use the new UUID default for sharded collections?
No, it's just the new default. You can still explicitly specify a different shard key when creating a collection if your use case requires it.
Can I use transactions on a standalone MongoDB instance?
No. Multi-document transactions are only supported in replica set deployments, as they rely on the replication protocol for atomicity and durability.
What happens if my aggregation type conversion fails with $convert?
That's the beauty of it. You define the failure behavior. You can specify an onError value to substitute in case of a conversion error, or an onNull value if the input is null, keeping your pipeline from breaking.
Is it difficult to upgrade from 3.6 to 4.0?
The upgrade process is straightforward but has prerequisites. Your featureCompatibilityVersion must be set to "3.6" first, and you must upgrade through the correct version sequence (e.g., 3.4 -> 3.6 -> 4.0). Always test the upgrade in a staging environment first.