MongoDB 8.0 Architecture Upgrades for Speed and Reliability - ApsaraDB for MongoDB

MongoDB 8.0 delivers significant performance improvements and new capabilities across memory management, replication, sharding, aggregation, and security. This topic summarizes the key changes to help you assess the upgrade and understand how they affect your applications.

For the full upstream changelog, see MongoDB 8.0 release notes.

Advanced TCMalloc

MongoDB 8.0 replaces the previous memory allocator with an advanced TCMalloc version that reduces memory fragmentation and sustains performance under heavy load. Two key changes drive the improvement:

Per-CPU caching: Advanced TCMalloc uses a cache per CPU core instead of per thread, reducing memory fragmentation and enabling the database to handle higher concurrent workloads.
Background memory release: A background thread attempts to release unused memory back to the operating system every second.

The tcmallocReleaseRate parameter controls the release rate in bytes/s. Before MongoDB 8.0, this parameter accepted a vague range of 1–10. In ApsaraDB for MongoDB, the default value is 10485760 (10 MB). Even when set to 0, the allocator still releases some memory. Adjust this value based on your workload requirements.

Replication performance

"Majority" write concern behavior change

Starting in MongoDB 8.0, when writeConcern is set to majority, MongoDB acknowledges the write after the oplog entry has been written to the majority of replica set members — without waiting for those members to apply the change. This improves write throughput in majority mode.

Potential impact: If your application reads from a secondary node immediately after receiving a majority write acknowledgment, the query may return results that do not include the changes from that write.

Parallel oplog write and apply

Secondary nodes now write and apply oplog batches in parallel:

A Writer thread reads new oplog entries from the primary node and writes them to the local oplog.
An Applier thread asynchronously applies those changes to the local database.

This improves replication throughput on secondary nodes. The related serverStatus metrics are now reported as metrics.repl.buffer.write and metrics.repl.buffer.apply.

Resharding performance

reshardCollection is significantly faster in MongoDB 8.0. The new forceRedistribution option lets you reshard a collection using its existing shard key and redistribute data to new shards. This completes faster than migrating a chunk to a specific range. Combine forceRedistribution with the zones option to migrate data to a specific zone.

db.adminCommand({
    reshardCollection: "db.coll",
    key: { shard_key: "hashed" },
    forceRedistribution: true
})

Note

Building indexes during resharding can cause index builds to fail silently, without explicit error messages. Complete all index builds before starting resharding, or avoid building indexes while resharding is in progress.

During the incremental oplog catch-up stage, the source shard blocks writes to the collection only when the estimated remaining time is within two seconds, then waits for the destination shard to complete catch-up. If your use case can tolerate a longer blocking window — for example, during a maintenance window — run the commitReshardCollection command to block writes immediately and accelerate resharding completion.

For more information, see Resharding process and Shard a collection.

Sharding

In addition to the resharding improvements above, MongoDB 8.0 includes the following sharding changes:

Hashed sharding default: Hashed sharding creates 1 chunk per shard by default (down from 2 chunks before MongoDB 8.0).
`dbHash` on shards: The dbHash command can now run on individual shards.
Partial shard keys in queries: findAndModify and deleteOne accept partial shard keys as query predicates.
`updateOne` with upsert: When using updateOne with upsert: true on a sharded collection, all shard key fields can be omitted from the query predicate.
`unshardCollection`: Removes sharding from an existing collection and moves all documents to a specific shard, or to the shard with the least data.
`moveCollection`: Moves an unsharded collection to a specific shard, independent of the primary shard. Time series collections and Queryable Encryption collections cannot be moved. Write operations are blocked for approximately 2 seconds during the move.

The following commands and mongosh helper functions are now available:

Command	mongosh helper	Description
`moveCollection`	`sh.moveCollection()`	Moves an unsharded collection to a specific shard.
`unshardCollection`	`sh.unshardCollection()`	Removes sharding from a collection and moves all data to a specific shard.
`abortMoveCollection`	`sh.abortMoveCollection()`	Cancels an in-progress `moveCollection` operation.
`abortUnshardCollection`	`sh.abortUnshardCollection()`	Cancels an in-progress `unshardCollection` operation.
None	`sh.shardAndDistributeCollection()`	Shards a collection and immediately redistributes data with an existing shard key. Equivalent to running `shardCollection` followed by `reshardCollection`.

Logging

The workingMillis field is added to slow query logs. It shows the time MongoDB actually spent processing the operation, which is useful for identifying true performance bottlenecks.

Unlike durationMillis — which reflects total operation latency including lock wait or traffic throttling — workingMillis excludes those external wait times. Use workingMillis when you want to measure actual processing time independently of queue or lock contention.

Aggregation

BinData conversion

The $convert operator now supports the following conversions:

String to BinData
BinData to string

The $toUUID expression provides a shorthand for converting string values to UUID.

$queryStats

The $queryStats aggregation stage returns statistics for recorded queries. In MongoDB 8.0, it also tracks and reports metrics in change streams more efficiently.

Database security

Queryable Encryption: range queries

Queryable Encryption now supports range queries on encrypted fields using $lt, $lte, $gt, and $gte.

Entrance queue

MongoDB 8.0 introduces an entrance queue (ingressAdmissionControllerTicketPoolSize) for incoming network requests. Operations received from the network enter this queue before being admitted to the database.

The queue is unlimited by default. Set a maximum queue size to bound the number of queued requests and prevent unbounded queueing under traffic spikes.

Other optimizations

Query shapes and query settings

MongoDB 8.0 introduces a new Query Shape concept. The previous query shape is now called the plan cache query shape. Use query settings (not index filters) to influence query plan selection — planCacheSetFilter for setting index filters is no longer supported in MongoDB 8.0.

Three commands manage query settings:

setQuerySettings: Specify index hints or set a reject policy for a specific Query Shape to block it from executing.
removeQuerySettings: Delete query settings for a Query Shape.
$querySettings: View current query settings.

Query plan optimization time

explain() output now includes queryPlanner.optimizationTimeMillis, which reports the time spent on query plan optimization in milliseconds.

Default read operation timeout

The new defaultMaxTimeMS parameter sets a default time limit (in milliseconds) for read operations. It applies to find, aggregate (excluding the $merge and $out stages), count, distinct, and dbHash. If the client specifies maxTimeMS on an individual operation, that value takes precedence.

bulkWrite command

The new bulkWrite command runs multiple insert, update, and delete operations across multiple collections in a single request.

Additional changes

`updateOne` sorting: updateOne now supports the sort option.
TTL indexes on capped collections: TTL indexes can now be created on capped collections.
Bulk insert oplog batching: Non-transactional bulk inserts are now written as a single oplog entry instead of separate entries. All inserted documents share the same clusterTime in change stream events. This improves bulk insert performance and reduces replication lag from replaying multiple oplogs on secondary nodes.
Concurrent DDL operations: Different collections in the same database can now undergo DDL operations simultaneously.
Shard membership changes during DDL: Adding or removing shards from a sharded cluster is blocked while DDL operations (such as reshardCollection) are in progress. Complete DDL operations before modifying shard membership.

Index building improvements

MongoDB 8.0 improves error reporting and resilience for index builds:

Aspect	MongoDB 8.0	Before MongoDB 8.0
Error reporting	Errors detected during the collection scan phase (except duplicate key errors) are returned immediately, and index building stops.	Errors detected during collection scan are returned only in the commit phase at the end of index building, increasing time to diagnosis.
Secondary node resilience	On index build error, secondary nodes can request the primary to stop index building and do not crash. (If a secondary has already voted to commit, it cannot stop and will crash — consistent with MongoDB 7.0 behavior.)	Index build errors may cause secondary nodes to crash.
Disk space management	If available disk space drops below `indexBuildMinAvailableDiskSpaceMB`, index building stops automatically. (Does not stop if the member has already voted to commit.)	Index building also stops on insufficient disk space.