ApsaraDB for MongoDB:Overview of new features in MongoDB 7.0

What's new at a glance

Queryable encryption

Queryable Encryption, which was in preview in MongoDB 6.0, is generally available in MongoDB 7.0.

For implementation details, see Queryable Encryption.

Shard metadata consistency check

Metadata inconsistencies across shards can cause subtle routing errors that are difficult to diagnose after the fact. The checkMetadataConsistency command, added in MongoDB 7.0, lets you proactively detect these inconsistencies before they affect production traffic.

Run the command at the database level:

// Check metadata consistency for the current database
db.runCommand({
  checkMetadataConsistency: 1,
  checkIndexes: true
})

Or use the mongosh helpers to check at different scopes:

// Check the current database
db.checkMetadataConsistency()

// Check a specific collection
db.collection.checkMetadataConsistency()

// Check all databases in the sharded cluster
sh.checkMetadataConsistency()

Include this check in your routine operations and maintenance (O&M) schedule to catch inconsistencies early. For the full command reference, see checkMetadataConsistency.

Shard key analysis (analyzeShardKey)

Choosing the wrong shard key leads to hotspots, uneven data distribution, and degraded query performance — problems that are expensive to fix after a collection is sharded. The analyzeShardKey command evaluates a candidate shard key against sampled real-world queries so you can make an informed decision before committing.

db.adminCommand({
  analyzeShardKey: "<db>.<collection>",
  key: <shardKey>,
  keyCharacteristics: <bool>,
  readWriteDistribution: <bool>,
  sampleRate: <double>,
  sampleSize: <int>
})

The command does not block reads or writes on the collection. To minimize impact on production workloads, use it with the secondary or secondaryPreferred read preference. On a sharded cluster, mongos automatically sets the read preference to secondaryPreferred.

To configure query sampling before running the analysis, see configureQueryAnalyzer. For the full command reference, see analyzeShardKey.

AutoMerger

As a sharded cluster evolves — through data migration, range deletions, and continuous writes — the number of chunks can grow beyond what is needed, causing uneven data distribution and slowing down the balancer. AutoMerger, introduced in MongoDB 7.0, addresses this by automatically merging chunks when data or index distribution is imbalanced, when too many chunks exist, or during data migration.

AutoMerger is enabled by default in MongoDB 7.0. The configureCollectionBalancing command, which was introduced in earlier versions of MongoDB to configure balancer settings for a sharded collection, also supports AutoMerger:

db.adminCommand({
  configureCollectionBalancing: "<db>.<collection>",
  chunkSize: <num>,
  defragmentCollection: <bool>,
  enableAutoMerger: <bool>
})

To manually trigger a merge of all mergeable chunks on a specific shard, run:

db.adminCommand({ mergeAllChunksOnShard: "db.coll", shard: "Shard0" })

Sharding optimizations

In addition to AutoMerger, MongoDB 7.0 includes the following sharding changes:

• `rangeDeleterHighPriority` parameter: Controls whether deletion of orphan documents takes priority over business delete operations. Defaults to false, meaning business operations take priority.

• Removed `operationsBlockedByRefresh`: The operationsBlockedByRefresh document has been removed from serverStatus. The counters were incrementing on mongos nodes for every operation that used collection routing information, even when no catalog cache refresh was occurring, making the metrics misleading.

• Resharding metrics: New monitoring metrics for resharding operations have been added.

• `addShard` command: The maxSize option is no longer supported.

• Chunk size validation: When you adjust the chunk size in the config.settings collection, MongoDB now validates that the value falls within the supported range of 1 to 1,024.

• Balancer policy updates (from MongoDB 6.0.3): The balancer now distributes data based on data volume rather than chunk count. Partitioning is performed by range instead of by chunk, and automatic splitting only occurs when data is migrated across shards.

Security

• KMIP support: Key Management Interoperability Protocol (KMIP) V1.0 and V1.1 are now supported for external key management.

• OpenSSL: OpenSSL 3.0 and OpenSSL FIPS are now supported.

Aggregation

MongoDB 7.0 adds six new aggregation operators.

db.sales.aggregate([
  {
    $group: {
      _id: "$category",
      medianRevenue: { $median: { input: "$revenue", method: "approximate" } },
      p90Revenue: { $percentile: { input: "$revenue", p: [0.90], method: "approximate" } }
    }
  }
])

Time series collections

• Relaxed DELETE restrictions: The DELETE command can now be used on time series collections without most of the restrictions that applied in earlier versions. The only remaining restriction is that DELETE cannot be used inside a multi-document transaction.

• COMPACT support: The COMPACT command now works with time series collections.

Other changes

• Slow query log fields: New fields, including catalogCacheIndexLookupDurationMillis, have been added to slow query log entries. See Logging slow operations.

• Automatic storage engine concurrency: Transaction concurrency for the WiredTiger storage engine is now automatically tuned. The default value before auto-tuning is 128 tickets. See Concurrent storage engine transactions (read and write tickets).

• Query sampling metrics in `currentOp`: Fields related to query sampling are now included in the currentOp output. See currentOp metrics.

• Compound wildcard indexes: MongoDB 7.0 supports compound wildcard indexes, which combine a wildcard field with one or more standard fields. See Compound wildcard indexes.

• `$changeStreamSplitLargeEvent` operator: Splits change stream events that exceed the 16 MB BSON document limit into multiple smaller events. See Large change stream events.

• Slot-Based Execution (SBE) engine improvements: The SBE query execution engine has been optimized for better query performance.

• Chunk migration metrics: New sharding statistics for chunk migrations have been added. See New sharding statistics for chunk migrations.

• `USER_ROLES` system variable: Returns the roles assigned to the current user.

• New global parameters: Parameters for analyzeShardKey, balancer, and queryAnalyzers have been added.

• `serverStatus` output changes: Additional fields have been added to the serverStatus output. See serverStatus output change.