All Products
Search

This Product

    ApsaraDB for MongoDB:Versions and storage engines

    Document Center

    ApsaraDB for MongoDB:Versions and storage engines

    Last Updated:Sep 16, 2026

    This topic describes the versions, storage engines, and compatibility of ApsaraDB for MongoDB to help you select an instance that best fits your business requirements.

    Supported versions

    ApsaraDB for MongoDB supports the following versions:

    Note

    You can manually upgrade the database major version of a running instance. However, you cannot downgrade. For more information, see Upgrade database major version.

    Storage engines

    Storage engine

    Scenario

    Description

    WiredTiger

    The default storage engine for most workloads.

    It organizes data using a B-tree structure and offers significant performance improvements over MongoDB's earlier MMAPv1 storage engine. It also supports data compression to reduce storage costs.

    Version and storage engine compatibility

    Storage engine

    MongoDB 4.4 and later

    MongoDB 4.2

    MongoDB 4.0

    MongoDB 3.4 (Discontinued)

    WiredTiger

    • replica set instance

    • sharded cluster instance

    • replica set instance

    • sharded cluster instance

    • standalone instance

    • replica set instance

    • sharded cluster instance

    • standalone instance

    • replica set instance

    • sharded cluster instance

    MongoDB 8.3

    This version introduces new features, including enhanced aggregation, a refactored sharding management process, in-progress slow query logs, and query-level memory tracking. It also brings optimizations to performance, system parameters, indexes, and time series.

    • Enhanced aggregation: Adds array index access, new expressions such as $hash and $hexHash, and improved type conversion for $toString and $convert.

    • Refactored sharding management process: The removeShard command is deprecated and replaced with a four-stage process using the startShardDraining, stopShardDraining, shardDrainingStatus, and commitShardRemoval commands. This new process supports pause and resume operations.

    • Enhanced monitoring and diagnostics: Adds in-progress slow query logs, query-level memory tracking (inUseTrackedMemBytes and peakTrackedMemBytes), and on-demand output for serverStatus.

    • Performance and system parameters: Adds new parameters for pre-authenticated connection resource control, automatic resource reclamation under cache pressure, and overload-aware service selection.

    • Index changes: Increases the default value of 2dsphereVersion to 4, prioritizing GeoJSON over legacy coordinate pairs.

    For more information, see What's New in MongoDB 8.3.

    MongoDB 8.0

    This release introduces an upgraded TCMalloc, optimized replication and resharding performance, and enhancements to sharding, logging, aggregation, and security.

    • Upgraded TCMalloc

      The upgraded TCMalloc uses per-CPU caches instead of per-thread caches to reduce memory fragmentation and improve database resilience under heavy workloads. Additionally, the upgraded TCMalloc creates a background thread that attempts to release memory back to the operating system every second.

    • Replication performance

      Starting with MongoDB 8.0, when writeConcern is set to majority, MongoDB acknowledges a write once a majority of replica set members write the corresponding oplog entries, without waiting for the changes to be applied. This change improves write performance in majority mode.

      Secondary members now write and apply oplog batches in parallel. While a writer thread reads new oplog entries from the primary member and writes them to the local oplog, an applier thread asynchronously applies these changes to the local database. This change improves replication throughput on secondary members.

    • Resharding performance

      MongoDB 8.0 introduces the forceRedistribution option, which allows you to reshard a collection with the same shard key, redistributing data across new shards. This process is significantly faster than range-based chunk migration and can be used with the zones option to move data to specific zones.

    • Sharding

      • Hashed sharding now creates one chunk per shard by default, compared to two chunks in versions before MongoDB 8.0.

      • The dbhash command can now run directly on a shard.

      • The findAndModify and deleteOne commands can now use a partial shard key in the query filter.

      • When you use the updateOne command with upsert set to true on a sharded collection, the query filter no longer needs to include the full shard key.

      • You can now unshard an existing collection by using the unshardCollection command or the sh.unshardCollection() method. This operation moves all documents in the collection to a specified shard or the least-loaded shard.

      • The moveCollection command now allows you to move an unsharded collection to a specific shard, without being restricted to the primary shard. However, time series collections and collections with queryable encryption cannot be moved. This operation may briefly block writes to the collection for about two seconds.

      • This release introduces new database commands and mongosh helpers:

        Command

        Mongosh helper

        Description

        moveCollection

        sh.moveCollection()

        Moves an unsharded collection to a specific shard.

        unshardCollection

        sh.unshardCollection()

        Unshards an existing sharded collection and moves its data to a specific shard.

        abortMoveCollection

        sh.abortMoveCollection()

        Stops an in-progress moveCollection operation.

        abortUnshardCollection

        sh.abortUnshardCollection()

        Stops an in-progress unshardCollection operation.

        None

        sh.shardAndDistributeCollection()

        Shards a collection and immediately redistributes the data using the provided shard key.

        Running this helper is equivalent to running shardCollection and reshardCollection sequentially and is intended to speed up data movement.

    • Logging

      The slow query log now includes a workingMillis field, which shows the time an operation was actively executing.

      Unlike durationMillis, which measures the total operation latency, workingMillis does not include time spent waiting for resources, such as locks or flow control.

    • Aggregation

      • binData conversion

        The $convert operator now supports the following conversions:

        • Convert string values to binData values.

        • Convert binData values to string values.

        Additionally, the $toUUID expression provides a simplified syntax for converting strings to UUID values.

      • $queryStats

        The $queryStats stage returns statistics for logged queries and improves metric tracking and reporting in a change stream.

    • Security

      • Queryable encryption

        You can use $lt, $lte, $gt, and $gte to perform range queries on encrypted fields.

      • Ingress queue

        MongoDB 8.0 introduces a new queue for ingress admission control (ingressAdmissionControllerTicketPoolSize). Operations entering the database from the network enter this ingress queue.

        By default, the ingress queue is unlimited, but you can configure its maximum size.

    • Other optimizations

      • This release introduces a new Query Shape. The previous query shape is now referred to as the Plan Cache Query Shape. The query optimizer also uses Query Settings as additional input, which affects the final query plan selection.

        • setQuerySettings adds query settings:

          • You can use this command to specify an index for selection. MongoDB 8.0 deprecates the use of planCacheSetFilter to set an index filter.

          • You can use this command to configure rate limiting. The reject option allows you to reject a specific Query Shape.

        • removeQuerySettings deletes query settings.

        • $querySettings displays query settings.

      • The explain() command now returns the time spent on query plan optimization in milliseconds through queryPlanner.optimizationTimeMillis.

      • The new defaultMaxTimeMS parameter specifies the default time limit in milliseconds for a single read operation to complete.

        • Applicable operations:

          • find

          • aggregate (excluding the $merge and $out stages)

          • count

          • distinct

          • dbHash

        • If a client specifies maxTimeMS, defaultMaxTimeMS is ignored for that operation.

      • The new bulkWrite command allows you to perform multiple insert, update, and delete operations on multiple collections in a single request.

      • The updateOne command now supports the sort option.

      • You can now create a TTL index on a capped collection.

      • Non-transactional bulk inserts are now batched into a single oplog entry instead of generating a separate entry for each insert. All inserted documents share the same clusterTime in change stream events. This change improves bulk insert performance and helps prevent replication lag that could occur when secondary members replay multiple oplog entries.

      • Concurrent DDL operations can now run on different collections within the same database.

      • Adding or removing shards is blocked while a DDL operation that modifies a collection, such as reshardCollection, is running on the cluster. You can perform these actions only after the DDL operation is complete.

      • Index builds are now faster to report errors and have greater fault resilience.

        Behavior

        MongoDB 8.0

        Before MongoDB 8.0

        When an index build stops due to an error

        Index errors, except for duplicate key errors, found during the collection scan phase are returned immediately, stopping the index build.

        MongoDB 8.0 helps you diagnose index errors more quickly. For example, if an incompatible index value format is found, the error is returned immediately.

        Index errors found during the collection scan were reported during the commit phase at the end of the index build.

        Compared with MongoDB 8.0, an index build error could take much longer to return because it was reported only during the commit phase.

        Resilience

        A secondary member can ask the primary member to stop an index build if an error occurs. This improves deployment resilience by preventing the secondary from crashing.

        A request to stop an index build is not always feasible. If a member has already voted to commit the index, the secondary member cannot request to stop the build and will crash, similar to the behavior in MongoDB 7.0 and earlier.

        Index build errors could cause secondary members to crash.

        Disk space

        An index build is automatically aborted if the available disk space falls below the minimum value specified in the indexBuildMinAvailableDiskSpaceMB parameter.

        The index build does not stop if the member has already voted to commit the index.

        Index builds were also aborted if disk space was insufficient.

    MongoDB 7.0

    This release introduces new features such as queryable encryption, shard metadata consistency check, sampled queries and shard key analysis (analyzeShardKey), and the AutoMerger. It also includes enhancements and optimizations for sharding, time series collections, aggregation, and security.

    • Queryable encryption

      Queryable encryption was available as a preview feature in MongoDB 6.0. In MongoDB 7.0, this feature is now Generally Available (GA). For more information, see Queryable Encryption.

    • Shard metadata consistency check

      MongoDB 7.0 introduces the checkMetadataConsistency command to check for metadata inconsistencies across different shards. Add this check to your routine maintenance procedures to detect potential inconsistencies early. For more information, see checkMetadataConsistency.

    • Sampled query and shard key analysis

      This release supports analyzing the suitability of a collection's shard key based on the results of sampled queries. This can help you design a more effective schema and shard key and make better use of your sharding architecture. For more information, see analyShardKey and configureQueryAnalyzer.

    • AutoMerger

      MongoDB 7.0 introduces a new AutoMerger for the Balancer. When data or index distribution is uneven, there are too many chunks, or during data migration, the AutoMerger merges chunks to balance data and improve performance. This feature is enabled by default in MongoDB 7.0, and you can manage it through the Balancer's active window.

    • Sharding

      • You can now use the rangeDeleterHighPriority parameter to assign a higher priority to the deletion of orphan documents. By default, this parameter is set to false because application-level deletions typically have higher priority.

      • The operationsBlockedByRefresh monitoring metric, which tracked catalog cache refresh behavior, is no longer supported because every operation on mongos that used collection routing information would increment this counter.

      • This release adds new monitoring metrics for resharding.

      • The addShard command no longer supports the maxSize option.

      • When you adjust the chunk size for the config.settings collection, a validation check now limits the value to the range [1, 1024].

      • Starting from MongoDB 6.0.3, several adjustments have been made to the Balancer policy:

        • The Balancer no longer balances based on the difference in the number of chunks across shards. Instead, it balances based on the difference in data size across shards.

        • A range replaces the logical concept of a chunk.

        • Auto-splitting occurs only when ranges move across shards.

    • Time series collections

      • This release removes the operational restrictions on the DELETE command for time series collections. The DELETE command now has no limitations, except that it cannot be used in multi-document transactions.

      • The COMPACT command now supports time series collections.

    • Aggregation

      This release introduces the following operators to support bitwise calculations and percentiles:

      Parameter

      Description

      $bitAnd

      Returns the result of a bitwise AND operation on an Int32 or Int64 value.

      $bitNot

      Returns the result of a bitwise NOT operation on an Int32 or Int64 value.

      $bitOr

      Returns the result of a bitwise OR operation on an Int32 or Int64 value.

      $bitXor

      Returns the result of a bitwise XOR operation on an Int32 or Int64 value.

      $median

      Returns the approximate median, which is equivalent to the 50th percentile.

      $percentile

      Returns the value for a specified percentile.

    • Security

      • MongoDB supports KMIP 1.0 and 1.1.

      • MongoDB supports OpenSSL 3.0 and OpenSSL FIPS.

    • Other optimizations

      • Slow query logs now include new fields, such as catalogCacheIndexLookupDurationMillis. For more information, see log messages for slow queries.

      • Starting from MongoDB 7.0, MongoDB automatically and dynamically adjusts the concurrency of storage engine transactions, which previously had a default value of 128. For more information, see Concurrent Storage Engine Transactions.

      • The currentOp command now includes new fields related to query sampling. For more information, see currentop-metrics.

      • This release adds support for compound wildcard indexes. For more information, see Compound Wildcard Indexes.

      • The new $changeStreamSplitLargeEvent operator supports splitting large change events that exceed 16 MB. For more information, see Large Change Stream Events.

      • This release improves the performance of the slot-based query execution engine.

      • This release adds new metrics for chunk migrations. For more information, see New Sharding Statistics for Chunk Migrations.

      • You can now use the USER_ROLES system variable to retrieve the roles of the current user.

      • This release adds new global parameters related to analyzeShardKey, balancer, and queryAnalyzers.

      • The output of the serverStatus command now includes additional fields. For more information, see serverStatus Output Change.

    MongoDB 6.0 release notes

    This release introduces new features such as queryable encryption and Cluster-to-Cluster Sync. It also includes enhancements and optimizations for time series collection, change stream, aggregation, query, elasticity, and security.

    • Queryable encryption

      Queryable encryption allows you to encrypt sensitive data on the client side, store it as fully randomized encrypted data on the database server, and run expressive queries on the encrypted data.

      With queryable encryption, plaintext data is only ever visible on the client side. When a query is sent to the server, it includes an encryption key from a Key Management Service (KMS). The server processes the query against the ciphertext and returns an encrypted result. The client then uses the key to decrypt the result and display the plaintext data.

    • Cluster-to-Cluster Sync

      This release introduces mongosync, a new synchronization tool that supports continuous, unidirectional data synchronization between two MongoDB clusters. It works across any environment, including hybrid, Atlas, on-premises, and edge environments. You can also control and monitor the synchronization process in real time, and start, stop, resume, or reverse the sync as needed.

    • Time series collection

      This release enhances time series collection with improvements to indexing, queries, and sorting.

      • Adds support for a secondary index and a compound index to improve read performance.

      • Introduces geospatial indexing for time-series data. This allows you to add geographic information to your data, which helps with analysis in scenarios involving distance and location.

        For example, you can track temperature changes in refrigerated trucks or monitor the fuel consumption of cargo ships on specific routes.

      • Optimizes last point queries on time series data. You no longer need to scan an entire collection to query the last data point.

      • Improves sorting performance for time series data. Sorting operations now run more efficiently by using a clustered index and a secondary index on time and metadata fields.

    • Change stream

      This release introduces the following new features and optimizations:

      • Supports viewing a document pre-image.

        Note

        MongoDB versions earlier than 6.0 support only post-images. Starting in MongoDB 6.0, you can view both pre-images and post-images. For more information, see Change Streams with Document Pre- and Post-Images.

      • Adds support for DDL statements such as create, createIndexes, modify, and shardCollection. For more information, see Change Events.

      • Change events now include the wallTime field. The timestamp supports various conversion and display operators, including $toDate, $tsSeconds, and tsIncrement, making it easier for applications to consume.

    • Aggregation

      This release introduces the following new features and optimizations:

      • Sharded cluster instances now support $lookup and $graphLookup.

      • Improves support for joins with $lookup.

      • Enhances graph traversal capabilities with $graphLookup.

      • Improves the performance of $lookup by up to 100x in some scenarios.

      Note

      For more information about $lookup and $graphLookup, see $lookup (aggregation) and $graphLookup (aggregation).

    • Query

      Adds new operators such as $maxN, $topN, $minN, $bottomN, $lastN, and $sortArray. These operators offload computational work from the application to the database, making the application layer more lightweight.

      Note

      For more information about these operators, see Aggregation Pipeline Operators.

    • Elasticity

      This release introduces the following new features and optimizations:

      • The default chunk size increases from 64 MB to 128 MB. This reduces the frequency of data migrations and lowers network and routing overhead.

      • Adds support for the configureCollectionBalancing command, which allows you to:

        • Set different chunk sizes for different sharded collections.

          For example, you can increase the chunk size to 256 MB for very large sharded collections, or decrease it to 64 MB or 32 MB for smaller collections to distribute data more evenly across shards.

        • Actively defragment collections.

          Compared to the compact command, configureCollectionBalancing defragments collections more effectively, significantly reducing disk space usage.

        Note

        For more information about the configureCollectionBalancing command, see configureCollectionBalancing.

      • Security

        This release optimizes the Client-Side Field-Level Encryption (CSFLE) feature. CSFLE now supports any key management provider that complies with the Key Management Interoperability Protocol (KMIP). In addition to using a local key file, you can now integrate MongoDB with third-party key management appliances through KMIP for enhanced security.

        Note

        The CSFLE feature is often used to manage sensitive data, especially during data migrations.

    MongoDB 5.0

    MongoDB 5.0 marks the beginning of a new release cycle designed to deliver new features to users more quickly.

    • Native time series platform

      MongoDB 5.0 extends the general-purpose data platform to simplify time series data processing and expand its use cases into areas like IoT, financial analytics, and logistics.

    • Live resharding

      Simply run the reshardCollection command in the MongoDB Shell, select the database and collection to reshard, and specify the new shard key.

      reshardCollection: "<database>.<collection>", key: <shardkey>
      Note

      • <database>: The name of the database to reshard.

      • <collection>: The name of the collection to reshard.

      • <shardkey>: The name of the new shard key.

      • When you run the reshardCollection command, MongoDB clones the existing collection and applies all of its oplog entries to the new collection. After applying all entries, MongoDB switches to the new collection and deletes the old one in the background.

    • Versioned API

      The Versioned API allows MongoDB to add new features and improvements in each release while maintaining backward compatibility. If you need to change an API, you can introduce a new version and run it on the same server alongside existing API versions. As MongoDB accelerates its release schedule, the Versioned API helps you use the latest features more quickly and easily.

      The Versioned API defines a stable set of the most-used commands and parameters for an application. This set remains unchanged regardless of database updates from an annual Major Release or a quarterly Rapid Release. By decoupling the application lifecycle from the database lifecycle, you can pin your driver to a specific version of the MongoDB API. This ensures your application can run for years without code changes, even as the database evolves with new features and improvements.

    • Default majority write concern

      Starting with MongoDB 5.0, the default write concern level is majority. A write operation returns a success acknowledgment only after it is applied to the primary node and persisted to the oplog of a majority of secondary nodes. This provides stronger data durability guarantees out of the box.

    • Long-running snapshot queries

      Long-running snapshot queries add versatility and resilience to your applications. You can run queries that default to a 5-minute execution time (or a custom duration) while maintaining snapshot isolation consistent with the live transactional database. You can also perform snapshot queries on secondary nodes, enabling you to run different workloads on a single cluster and scale them across different shards.

    • New MongoDB Shell

      The MongoDB Shell (mongosh) has been redesigned from the ground up for a better user experience. It offers a modern command-line experience with enhanced usability and a powerful scripting environment. The new MongoDB Shell is now the default shell for the MongoDB platform. New features like syntax highlighting, intelligent autocompletion, contextual help, and useful error messages create an intuitive and interactive experience.

    • New release cadence

      Starting with MongoDB 5.0, MongoDB releases versions in two series: Major Releases and Rapid Releases. Rapid Releases are intended for development and evaluation purposes. Do not use Rapid Releases in a production environment.

    MongoDB 4.4 features

    This release addresses the most common user pain points from previous versions.

    • Hidden indexes

      You can hide an existing index to prevent its use in subsequent queries. This allows you to observe the performance impact of removing a potentially inefficient index before you permanently delete it.

    • Refinable shard keys

      You can add one or more suffix fields to an existing shard key to improve document distribution. This prevents requests from concentrating on a single shard, distributing the server load.

    • Compound hashed shard keys

      You can specify a single hashed field within a composite index. This greatly simplifies your application logic.

    • Hedged reads

      For a sharded cluster instance, you can send a read query to two members of a replica set within a shard simultaneously. The cluster then returns the result from the fastest-responding member to the client, which helps reduce query latency.

    • Streaming replication

      The primary node proactively streams the Oplog to secondary nodes. This method cuts the round-trip time by nearly half compared to the polling method in previous versions, improving replication performance.

    • Simultaneous indexing

      Indexes are built simultaneously on both the primary and secondary nodes. This significantly reduces replication lag during index builds and ensures secondary nodes can access the latest data promptly.

    • Mirrored reads

      The primary node can mirror a percentage of read traffic to secondary nodes. This ensures that secondary nodes handle a portion of the read load, which helps reduce application access latency.

    • Resumable initial sync

      This feature provides resumable transfer capability during the full synchronization process between a primary and a secondary node. This prevents the initial sync from restarting if a network interruption occurs.

    • Time-based oplog retention

      You can specify a custom retention period for the Oplog. This helps prevent the primary node from clearing Oplog entries too early, which could otherwise trigger a full synchronization.

    • Union

      The new $unionWith stage lets you combine data from multiple collections, similar to the union all function in SQL. This enhances MongoDB's query capabilities.

    • Custom aggregation expressions

      The new $accumulator and $function operators let you create custom aggregation expressions, improving API consistency and the overall user experience.

    Note

    To learn more about the new features in MongoDB 4.4, see MongoDB 4.4 Features.

    MongoDB 4.2

    This version uses two-phase commit to ensure the ACID properties of transactions in a sharded cluster. This feature greatly expands MongoDB's use cases.

    • Distributed transactions

      Two-phase commit ensures the ACID properties of transactions in a sharded cluster. This feature greatly expands MongoDB's use cases, marking a leap from a NoSQL to a NewSQL database.

    • Retryable reads

      Retryable reads automatically retry operations in unreliable network environments, simplifying your application logic and ensuring business continuity.

    • Wildcard indexes

      A wildcard index can cover multiple fields within a document, providing greater flexibility for schemas with non-deterministic fields and simplifying management.

    • Field-level encryption

      Field-level encryption is now available at the driver layer, letting you encrypt specific sensitive data, such as account names, passwords, prices, and phone numbers, without encrypting the entire database. This improves both flexibility and security.

    • Materialized views

      A materialized view caches computation results to avoid redundant calculations, improve operational efficiency, and reduce logical complexity.

    MongoDB 4.0

    This release is ideal for use cases requiring transaction support and NoSQL features, especially in the finance industry.

    • Support for cross-document transactions

      As the first NoSQL cloud database to support cross-document transactions, MongoDB 4.0 combines the speed and flexibility of the document model with the ACID guarantee.

    • 40% faster data migration

      Concurrent reads and writes enable new shard nodes to complete data migration faster and handle growing service workloads.

    • Significantly improved read performance

      With transaction support, secondary nodes no longer block read requests during oplog syncing. Furthermore, Alibaba Cloud supports multi-node scaling across all editions, substantially increasing read capacity.

    MongoDB 3.4 (discontinued)

    This version delivers several performance and security improvements over MongoDB 3.2.

    Note

    MongoDB 3.2 has been phased out. For more information, see [Notice] On February 4, ApsaraDB for MongoDB phased out version 3.2 and launched version 4.2.

    • Faster primary/secondary synchronization

      All indexes are now built during data synchronization, unlike in previous versions where only the _id index was created. A secondary node continuously reads new oplog entries to ensure its local database has enough storage for temporary data.

    • More efficient load balancing

      In MongoDB 3.2 and earlier, mongos nodes handled load balancing for a sharded cluster. Multiple mongos nodes would compete for a distributed lock, and the winning node migrated a chunk between shards. In MongoDB 3.4, this task moves to the primary node of the config server replica set, which significantly improves both the concurrency and efficiency of load balancing.

    • Richer aggregation operations

      Version 3.4 adds a large number of aggregation operators to provide more powerful data analysis capabilities. For example, bucket can conveniently classify data, $grahpLookup supports more complex relationship operations compared to $lookup from version 3.2, and $addFields enriches document operations, such as summing specific fields and storing the result as a new field.

    • Support for sharding zones

      This version introduces zones for a sharded cluster, replacing the previous tag-aware sharding mechanism. This feature allows you to assign specific data to one or more designated shards and simplifies deploying a sharded cluster across multiple data centers.

    • Support for collation

      Previously, strings were compared byte by byte. Collation lets you specify language-specific rules for string comparison, such as rules for lettercase and diacritics. This enables case-insensitive comparisons and sorting based on a specific locale.

    • Support for read-only views

      You can create a virtual collection from the results of a query on another collection or view. You can then run read operations on this view as you would on a standard collection.