Docs Menu
Docs Home
/
MongoDB Manual
/ /

Compatibility Changes in MongoDB 8.0

On this page

  • Query Behavior
  • Deprecations
  • Backward-Incompatible Features
  • General Changes
  • Aggregation

Starting in MongoDB 8.0, comparisons to null in equality match expressions don't match undefined values.

For example, consider these documents and query:

// people collection
[
{ _id: 1, name: null },
{ _id: 2, name: undefined },
{ _id: 3, name: [ "Gabriel", undefined ],
{ _id: 4, names: [ "Alice", "Charu" ] }
]
db.people.find( { name: null } )

Prior to MongoDB 8.0, the preceding query would match documents where:

  • The name field is null (_id: 1)

  • The name field is undefined or contains an undefined array element (_id: 2 and _id: 3)

  • The name field does not exist (_id: 4)

Starting in MongoDB 8.0, the preceding query does not match documents where the name field is undefined or contains undefined array elements. The query only matches documents where:

  • The name field is null or contains a null array element (_id: 1)

  • The name field does not exist (_id: 4)

This query behavior change also impacts these operations:

  • $eq

  • $in

  • $lookup, because a null local field no longer matches an undefined foreign field.

To learn how to rewrite your queries or migrate your data to account for this behavior change, see Migrate Undefined Data and Queries.

Deprecated
Description
LDAP

Starting in MongoDB 8.0, LDAP authentication and authorization is deprecated. LDAP is available and will continue to operate without changes throughout the lifetime of MongoDB 8. LDAP will be removed in a future major release.

For more details, see LDAP Deprecation.

LDAP migration information will be available in the future.

Hedged reads

Starting in MongoDB 8.0, hedged reads are deprecated. Queries that specify the read preference nearest no longer use hedged reads by default. If you explicitly specify a hedged read, MongoDB performs a hedged read and logs a warning.

Index filters

Deprecated in version 8.0.

Starting in MongoDB 8.0, use query settings instead of adding index filters. Index filters are deprecated starting in MongoDB 8.0.

Query settings have more functionality than index filters. Also, index filters aren't persistent and you cannot easily create index filters for all cluster nodes. To add query settings and explore examples, see setQuerySettings.

Server-side JavaScript functions

Starting in MongoDB 8.0, server-side JavaScript functions ($accumulator, $function, $where) are deprecated. MongoDB logs a warning when you run these functions.

tcmallocAggressiveMemoryDecommit
MongoDB 8.0 deprecates the tcmallocAggressiveMemoryDecommit parameter.
enableFinerGrainedCatalogCacheRefresh
MongoDB 8.0 deprecates the enableFinerGrainedCatalogCacheRefresh parameter.
timeField in shard key for time series collection

Starting in MongoDB 8.0, use of the timeField as a shard key in a time series collection is deprecated.

cleanupOrphaned
MongoDB 8.0 deprecates the cleanupOrphaned command. To confirm that no orphaned documents remain, use $shardedDataDistribution instead.
rangePreview

Starting in MongoDB 8.0, the rangePreview Queryable Encryption algorithm is deprecated and removed. Use the Range algorithm instead.

If your Queryable Encryption collection uses rangePreview, you must drop the collection before you can upgrade to MongoDB 8.0.

Starting in MongoDB 8.0, you can only run certain commands on shards. If you attempt to connect directly to a shard and run an unsupported command, MongoDB returns an error:

"You are connecting to a sharded cluster improperly by connecting directly
to a shard. Please connect to the cluster via a router (mongos)."

To run a non-supported database command directly against a shard, you must either connect to mongos or have the maintenance-only directShardOperations role.

MongoDB supports online transition from a replica set to a 1-shard cluster by allowing commands to be run directly against a shard. However, once the cluster has more than one shard, only the listed commands can be run directly against the shard without the maintenance-only directShardOperations role.

Starting in MongoDB 8.0, write operations that use the "majority" write concern return an acknowledgment when the majority of replica set members have written the oplog entry for the change. This improves the performance of "majority" writes. In previous releases, these operations would wait and return an acknowledgment after the majority of replica set members applied the change.

Starting in MongoDB 8.0, secondaries write and apply oplog entries for each batch in parallel. This introduces a breaking change for the metrics.repl.buffer status metric, as it now provides information on two buffers instead of one.

MongoDB 8.0 deprecates the following server status metrics:

It replaces them with these metrics:

Starting in MongoDB 8.0, Bulk.insert() and data ingestion workloads may perform better. However, shutting down MongoDB immediately after running these workloads might take longer because of the extra data being flushed to disk.

Starting in MongoDB 8.0, if you try to run multiple concurrent compact commands on the same collection, MongoDB returns an error.

Starting in MongoDB 8.0, you cannot use geospatial queries with malformed input. In prior versions, certain geospatial queries accept malformed input without an error.

Starting in MongoDB 8.0, when multiple identity providers (IDP) are defined, the oidcIdentityProviders parameter accepts duplicate issuer values as long as the audience value is unique for each issuer. This is also available in versions 7.3 and 7.0.

Starting in MongoDB 8.0, wiredTiger.concurrentTransactions is renamed to queues.execution.

Starting in MongoDB 8.0, null and missing field values in $denseRank and $rank sortBy operations are treated the same when calculating rankings. This change makes the behavior of denseRank and rank consistent with $sort.

Starting in MongoDB 8.0, $shardedDataDistribution only returns output for a collection's primary shard if the primary shard has chunks or orphaned documents.

For details, see $shardedDataDistribution.

Starting in MongoDB 8.0, MongoDB uses an upgraded version of TCMalloc that uses per-CPU caches, instead of per-thread caches, to reduce memory fragmentation and make your database more resilient to high-stress workloads.

To use the new TCMalloc with better performance, see TCMalloc Performance Optimization for a Self-Managed Deployment.

Back

8.0 (Stable Release)