ApsaraDB for MongoDB supports major version upgrades across its instance architectures. Before upgrading, review the available upgrade paths for your instance type and the compatibility changes introduced by each target version.
How upgrades work
Major version upgrades follow these rules:
One-way: Downgrade is not supported after a major version upgrade.
Instance must be running: The instance must be in the Running state before you start.
Kernel changes only: The compatibility changes described in this topic cover MongoDB kernel changes. Instance management feature changes are not included.
Instances that run MongoDB 4.0 or later support MongoDB 3.6 features. To use MongoDB 3.6 features, upgrade to MongoDB 4.0 or later — no separate 3.6 upgrade is needed.
Supported upgrade paths
Upgrade paths depend on your instance architecture and storage type. Instances on local disks or certain older versions cannot be upgraded in place — in those cases, create a new instance and migrate your data instead.
Standalone instance
| Instance category | Current version | Available upgrade |
|---|---|---|
| General-purpose cloud disk | MongoDB 4.0 | No new major version available |
| General-purpose cloud disk | MongoDB 3.4 | In-place upgrade not supported. Create a standalone instance and migrate your data |
Replica set instance
Cloud disk instances (general-purpose cloud disk, dedicated with cloud disks):
| Current version | Available upgrade |
|---|---|
| MongoDB 8.0 | No new major version available |
| MongoDB 7.0 | MongoDB 8.0 |
| MongoDB 6.0 | MongoDB 7.0 |
| MongoDB 5.0 | MongoDB 6.0 |
| MongoDB 4.4 | MongoDB 5.0 — see write performance warning |
Local disk instances (general-purpose local disks, dedicated local disks, dedicated host):
| Current version | Available upgrade |
|---|---|
| MongoDB 4.2 | In-place upgrade not supported. Create a replica set instance and migrate your data |
| MongoDB 4.0 | MongoDB 4.2 |
| MongoDB 3.4 | MongoDB 4.0 or MongoDB 4.2 |
| MongoDB 3.2 | — |
| MongoDB 3.0 | — |
Sharded cluster instance
Dedicated with cloud disks:
| Current version | Available upgrade |
|---|---|
| MongoDB 8.0 | No new major version available |
| MongoDB 7.0 | MongoDB 8.0 |
| MongoDB 6.0 | MongoDB 7.0 |
| MongoDB 5.0 | MongoDB 6.0 |
| MongoDB 4.4 | MongoDB 5.0 — see write performance warning |
Local disk instances (general-purpose local disks, dedicated local disks, dedicated host):
| Current version | Available upgrade |
|---|---|
| MongoDB 4.2 | In-place upgrade not supported. Create a sharded cluster instance and migrate your data |
| MongoDB 4.0 | MongoDB 4.2 |
| MongoDB 3.4 | MongoDB 4.0 or MongoDB 4.2 |
| MongoDB 3.2 | — |
| MongoDB 3.0 | — |
Cross-architecture and cross-storage-class migration
To upgrade across instance architectures or storage types (for example, from a local disk instance to a cloud disk instance), create a new instance running the target version and use Data Transmission Service (DTS) to migrate your data.
Migrate data using the appropriate DTS topic:
Compatibility changes by version
Review the compatibility changes for your target version before upgrading. Pay particular attention to high-impact changes that may affect your application behavior.
MongoDB 8.0
tcmallocAggressiveMemoryDecommitis not recommended.Use
tcmallocReleaseRateto control the memory release rate. The default in ApsaraDB for MongoDB is 10 MB/s.Comparisons to
nullno longer matchundefinedvalues. For example,{ name: null }returns documents wherenameisnull, but not wherenameisundefined.Index filters are not recommended.
timeFieldis not recommended as a shard key for time series collections.The
cleanupOrphanedcommand is not recommended.Multiple
compactcommands cannot run concurrently on a collection.Rename or delete any non-time-series
system.bucketscollections before upgrading.
For the full list, see Compatibility changes in MongoDB 8.0.
MongoDB 7.0
No compatibility issues exist when upgrading to MongoDB 7.0.
If you need to downgrade from 7.0 to an earlier version, remove the following before downgrading:
All columnar indexes
Cluster parameters registered with
setClusterParameter— see setClusterParameterAll collections created with the
encryptedFieldsoptionAll compound wildcard indexes
For the full list, see Compatibility changes in MongoDB 7.0.
MongoDB 6.0
Aggregation pipeline disk spill: If a pipeline processes more than 100 MB of data, MongoDB writes to temporary disk storage by default. To disable this, set
allowDiskUseByDefaulttofalse. In versions earlier than 6.0, use{ allowDiskUse: true }to enable disk spill explicitly.dropIndexeswith*drops all indexes except the_idindex and the last remaining shard key index — see dropIndexes.The
mongoshell is deprecated. Usemongoshinstead.Operators
$explain,$hint,$max, and$maxTimeMSare deprecated.If
expireAfterSecondsis set toNaNor0on a TTL index, expired documents may be evicted immediately.The
SCRAM-SHA-1authentication mechanism is deprecated.The
reIndexcommand andreIndex()method are deprecated.
For the full list, see Compatibility changes in MongoDB 6.0.
MongoDB 5.0
Read concern on secondary nodes: The default read concern level on secondary nodes changes from
availabletolocal— see Read Concern.Default write concern changes from `{w:1}` to `{w:majority}`: This is the highest-impact change in MongoDB 5.0. See the write performance impact section below.
db.collection.ensureIndex()is deprecated. Usedb.collection.createIndex()instead.The
saslStartandsaslContinuecommands now strictly validate parameters. The Go drivermgoadds an extramechanismparameter tosaslContinuethat is not supported — see mgo.The
geoSearchcommand is deprecated.
For the full list, see Compatibility changes in MongoDB 5.0.
MongoDB 4.4
The
forceoption is deprecated in thecompactcommand — see compact.The
geoSearchcommand is deprecated — see geoSearch.Indexes can be created on both the primary and secondary nodes concurrently, reducing the latency caused by index creation. During index builds, the secondary node can still access the latest data.
For the full list, see Compatibility changes in MongoDB 4.4.
MongoDB 4.2
The
geoNearcommand is deprecated. Use$geoNearin an aggregation pipeline instead — see $geoNear.The
repairDatabasecommand is deprecated.The
cloneCollectioncommand is deprecated. Usemongoexportandmongoimportinstead — see mongoexport and mongoimport.The
afterClusterTimeread concern option is deprecated — see Read Operations and afterClusterTime.Drivers compatible with MongoDB 4.2 or later enable retryable writes by default — see Retryable Writes.
The
group,copydb, andclonecommands are deprecated.
For the full list, see Compatibility changes in MongoDB 4.2.
MongoDB 4.0
The
reIndexcommand acquires a global exclusive (W) lock and blocks all other operations until the index rebuild completes — see reIndex.The
copydbandclonecommands are deprecated.
For the full list, see Compatibility changes in MongoDB 4.0.
MongoDB 3.6
Running
aggregatewithout a cursor option to return a single document is deprecated. Include thecursoroption unless you use theexplainoption — see aggregate.$type: "array"now returns only documents where the field itself is an array. In versions earlier than 3.6, it also returned documents where the field was an array containing at least one element of array type — see $type.The
findcommand now accepts an optionalsortoption — see find.$sortin an aggregation pipeline has a 100 MB memory limit — see $sort (aggregation).In multi-field update operations, fields are added in lexicographical order — see $set.
The
snapshotquery option is deprecated.
For the full list, see Compatibility changes in MongoDB 3.6.
MongoDB 3.4
The
groupcommand is deprecated. Usedb.collection.aggregate()ordb.collection.mapReduce()instead — see db.collection.aggregate() and db.collection.mapReduce().The
$inexpression withupsert: truehas updated behavior for determining whether matching documents exist:db.c.drop() // Cannot insert in MongoDB 3.4; can insert in versions earlier than 3.4 db.c.update({a:{$in:[1]}},{$addToSet:{a:2}},{upsert:true}) // Can insert in MongoDB 3.4 db.c.update({a:{$elemMatch:{$in:[2]}}},{$addToSet:{a:2}},{upsert:true})
For the full list, see Compatibility changes in MongoDB 3.4.
MongoDB 4.4 to 5.0 write performance impact
When upgrading from MongoDB 4.4 to 5.0, the default write concern changes from {w:1} to {w:majority}. This requires the primary node to wait for a majority of replica set members to acknowledge each write before returning success.
Impact: Write latency increases and overall write throughput may decrease, particularly for workloads with high write volumes or latency-sensitive operations.
Before upgrading, assess whether your application can tolerate increased write latency. To revert to the previous behavior after upgrading, run:
db.adminCommand({
setDefaultRWConcern: 1,
defaultWriteConcern: { w: 1 }
})For the command reference, see setDefaultRWConcern.
API reference
| Operation | Description |
|---|---|
| UpgradeDBInstanceEngineVersion | Upgrades the major version of an ApsaraDB for MongoDB instance |