Database Manual / Release Notes

Release Notes for MongoDB 8.0

This page describes changes and new features introduced in MongoDB 8.0.

MongoDB 8.0 is a Major Release, which means that it is supported for both MongoDB Atlas and on-premises deployments. MongoDB 8.0 includes changes introduced in MongoDB Rapid Releases 7.1, 7.2, and 7.3. This page describes changes introduced in those Rapid Releases and MongoDB 8.0.

MongoDB Atlas runs auto-upgrade for dedicated clusters (M10+) to Major version if Latest Release (auto-upgrades) option is enable. If you want to upgrade your MongoDB Atlas manually see Upgrade a Cluster to a New MongoDB Version, to learn more about MongoDB cluster versions in Atlas see Which versions of MongoDB do Atlas clusters use

To learn more about the differences between Major and Rapid releases, see MongoDB Versioning.

Warning

Past Release Limitations

The Critical Advisories below affect some prior MongoDB versions. If your deployment depends on features impacted by a Critical Advisory, upgrade to the latest available patch release.

IssueAffected Versions

SERVER-95067

8.0.0 - 8.0.3

SERVER-94559

8.0.0 - 8.0.3

Patch Releases

8.0.15 - Oct 2, 2025

This release contains security or reliability improvements. These release notes will be updated when more information is available.

8.0.14 - Sep 25, 2025

Issues fixed:

8.0.13 - Aug 21, 2025

Issues fixed:

8.0.12 - July 23, 2025

Issues fixed:

8.0.11 - Jun 30, 2025

Issues fixed:

8.0.10 - Jun 04, 2025

Issues fixed:

8.0.9 - May 1, 2025

Important

Fix for incorrect handling of incomplete data may prevent mongos from accepting new connections

Due to CVE-2025-6714, in MongoDB 8.0 prior to 8.0.9, MongoDB Server's mongos component can become unresponsive to new connections due to incorrect handling of incomplete data. This issue affects sharded MongoDB clusters that are configured with load balancer support for mongos using HAProxy on specified ports.

This issue affects the following MongoDB Server versions:

  • 8.0.0 - 8.0.8
  • 7.0.0 - 7.0.19
  • 6.0.0 - 6.0.22

CVSS Score: 7.5

CWE: CWE-834 Excessive Iteration AND CWE-400 Uncontrolled Resource Consumption

Issues fixed:

8.0.8 - Apr 14, 2025

Issues fixed:

8.0.7 - Apr 14, 2025

Important

MongoDB Server may be susceptible to privilege escalation due to $mergeCursors stage

Due to CVE-2025-6713, in MongoDB 8.0 prior to 8.0.7, an unauthorized user may leverage a specially crafted aggregation pipeline to access data without proper authorization due to improper handling of the $mergeCursors stage in MongoDB Server. This may lead to access to data without further authorization.

This issue affects the following MongoDB Server versions:

  • 8.0.0 - 8.0.6
  • 7.0.0 - 7.0.18
  • 6.0.0 - 6.0.21

CVSS Score: 7.7

CWE: CWE-285: Improper Authorization

Issues fixed:

  • SERVER-106752 MongoDB Server may be susceptible to privilege escalation due to $mergeCursors stage

8.0.6 - Mar 19, 2025

Issues fixed:

8.0.5 - Feb 20, 2025

Important

Pre-Authentication Denial of Service Vulnerability in MongoDB Server's OIDC Authentication

Due to CVE-2025-6709, in MongoDB 8.0 prior to 8.0.5, MongoDB Server is susceptible to a denial of service vulnerability due to improper handling of specific date values in JSON input when using OIDC authentication. This can be reproduced using the mongo shell to send a malicious JSON payload leading to an invariant failure and server crash.

This issue affects the following MongoDB Server versions:

  • 8.0.0 - 8.0.4
  • 7.0.0 - 7.0.16

The same issue affects MongoDB Server v6.0, but an attacker can only induce denial of service after authenticating. This issue affects the following MongoDB Server versions:

  • 6.0.0 - 6.0.20

CVSS Score: 7.5

CWE: CWE-20: Improper Input Validation

Important

Pre-authentication Denial of Service Stack Overflow Vulnerability in JSON Parsing via Excessive Recursion in MongoDB

Due to CVE-2025-6710, in MongoDB 8.0 prior to 8.0.5, MongoDB Server may be susceptible to stack overflow due to JSON parsing mechanism, where specifically crafted JSON inputs may induce unwarranted levels of recursion, resulting in excessive stack space consumption. Such inputs can lead to a stack overflow that causes the server to crash which could occur pre-authorisation.

This issue affects the following MongoDB Server versions:

  • 8.0.0 - 8.0.4
  • 7.0.0 - 7.0.16

The same issue affects MongoDB Server v6.0, but an attacker can only induce denial of service after authenticating. This issue affects the following MongoDB Server versions:

  • 6.0.0 - 6.0.20

CVSS Score: 7.5

CWE: CWE-674: Uncontrolled Recursion

Issues fixed:

  • SERVER-51366 Configure folders created by installer
  • SERVER-93497 Move user cache invalidation from OpObserver to onCommit handlers
  • SERVER-95672 Indexes on array fields that contain subarrays do not include some results
  • SERVER-97044 Fix an issue where change streams might incorrectly output a "drop" event during resharding or unsharding of a collection that is or was using zone sharding
  • SERVER-97860 Express path can return incorrect results when scanning a unique, multi-field index
  • SERVER-99290 Invalid timeseries buckets collections prevent completion of FCV 8.0 upgrade
  • SERVER-99345 Prevent sharding/moving a time-series buckets collection without the 'timeseries' options on FCV 8.0+
  • SERVER-106748 Pre-auth denial of service when accepting OIDC authentication
  • SERVER-106749 Pre-authentication Denial of Service Stack Overflow Vulnerability in JSON Parsing via Excessive Recursion in MongoDB
  • WT-12846 Fix how compact walk handles EBUSY from checkpoint flush_lock
  • All Jira issues closed in 8.0.5
  • 8.0.5 Changelog

8.0.4 - Dec 9, 2024

8.0.3 - Oct 24, 2024

Important

Improper neutralization of null bytes may lead to buffer over-reads in MongoDB Server

In MongoDB 8.0 and 8.0.1, an authorized user may trigger crashes or receive the contents of buffer over-reads of Server memory by issuing specially crafted requests that construct malformed BSON in the MongoDB Server.

This issue affects MongoDB Server versions:

  • 5.0.0 - 5.0.29
  • 6.0.0 - 6.0.18
  • 7.0.0 - 7.0.14
  • 8.0.0 - 8.0.1

Issues fixed:

8.0.1 - Oct 9, 2024

Issues fixed:

8.0.0 - Oct 2, 2024

The rest of this page describes changes and new features introduced in MongoDB 8.0.

Performance Improvements

MongoDB 8.0 introduces significant performance improvements from MongoDB 7.0, including, but not limited to:

  • Up to 36% better read throughput.
  • Up to 32% better performance for typical web applications.
  • Up to 20% faster concurrent writes during replication.

Note

The amount of performance improvement can vary depending on the configuration of your workloads and database instances.

Tip

MongoDB 8.0: Raising the Bar

New Bulk Write Command

Starting in MongoDB 8.0, you can use the new bulkWrite command to perform many insert, update, and delete operations on multiple collections in one request. The existing db.collection.bulkWrite() method only allows you to modify one collection in one request.

bulkWrite operations on MongoDB 8.0 can run up to 56% faster than bulk write operations on MongoDB 7.0.

Time Series Block Processing

Starting in version 8.0, MongoDB may execute certain time series queries using block processing. This performance improvement processes queries in "blocks" of data, rather than individual values. Block processing improves query execution speed and throughput when working with time series collections.

Compared to time series queries run on MongoDB 7.0 or earlier, block processing for time series data in MongoDB 8.0 may handle higher volumes of data and improve throughput in some cases by more than 200% for $group operations and analytical queries.

To see if your time series query uses block processing, check the explain.queryPlanner.winningPlan.slotBasedPlan.stages field in the explain plan output.

To learn more, see Block Processing.

Platform Support Updates

Starting in MongoDB 8.0, new MongoDB Server versions (major and minor) support the minimum operating system (OS) minor version defined by the OS vendor. After an OS minor version is no longer supported by the OS vendor, MongoDB updates the MongoDB Server to support the next OS minor version. For details, see MongoDB Platform Support Improvements.

MongoDB 8.0 supports the following minimum OS minor versions:

  • Red Hat Enterprise Linux 8.8
  • Red Hat Enterprise Linux 9.3
  • SUSE Linux Enterprise Server 15 SP5
  • Amazon Linux 2023 version 2023.3

Logging

Starting in MongoDB 8.0, you can configure the Database Profiler to log slow operations based on the time that MongoDB spends working on that operation, rather than the total latency for the operation. This means that factors such as waiting for locks and flow control do not affect whether an operation exceeds the slow operation threshold.

This change provides the following improvements for logging and query analysis:

  • Slow queries are logged more accurately based on the time MongoDB spends processing the query.
  • Query analysis tools such as the Query Profiler, Performance Advisor, and Search Query Telemetry report slow operations based on workingMillis instead of durationMillis. This change provides a more accurate view of problematic queries.
  • Slow query logs include a metric for the time queued on execution tickets, queues.execution.totalTimeQueuedMicros. This metric helps identify whether an operation is slow because of the time it takes to complete, or the time it spends waiting to start.

For more information, see db.setProfilingLevel().

Database Profiler

When you specify a filter for the database profiler, you can log operations based on the new workingMillis metric. You can log operations based on both workingMillis and durationMillis and set each metric to a different threshold.

Aggregation

BinData Conversion

Starting in MongoDB 8.0, you can use the $convert operator to perform the following conversions:

  • String values to binData values
  • binData values to string values

MongoDB 8.0 also includes a new helper expression, $toUUID, which provides simplified syntax for converting strings to UUID values.

$queryStats

Starting in MongoDB 7.1, the $queryStats stage returns statistics for recorded queries.

Change Stream Improvements

Starting in MongoDB 8.0, $queryStats improves tracking and reporting metrics for change streams. For more information, see $queryStats Change Streams Behavior.

$rank and $denseRank Behavior

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.

Security

Queryable Encryption Range Queries

Starting in MongoDB 8.0, Queryable Encryption supports range queries on encrypted fields using the $lt, $lte, $gt, and $gte operators. For details, see Supported Operations for Queryable Encryption. To enable range queries on encrypted fields, see Create an Encryption Schema.

OCSF Schema for Log Messages

Starting in MongoDB 8.0, you can specify the OCSF schema for audit log messages. The OCSF schema provides logs in a standardized format compatible with log processors.

To set the schema used for log messages, use the auditLog.schema configuration file option.

For example log messages in OCSF format, see OCSF Schema Audit Messages.

Ingress Queue

MongoDB 8.0 introduces a new queue for ingress admission control. Operations that wait for entry into the database from the network enter the ingress queue. By default, the queue is unrestricted, meaning that MongoDB allows all operations to execute through this stage without any queueing. Setting the queue maximum to a specific value allows you to queue operations at this stage if the number of concurrent operations reaches the specified limit.

Sharding

Starting in MongoDB 8.0, you can unshard collections and move unsharded collections between shards on sharded clusters.

Moving a Collection

Starting in MongoDB 8.0, you can move an unsharded collection to a different shard using the moveCollection command.

For details, see Moveable Collections. To get started, see Move a Collection.

Moving Collections that have Change Streams

Starting in MongoDB 8.0, movePrimary doesn't invalidate Event collections that have change streams. The change streams can continue to read events from collections after the collections are moved to a new shard.

For details, see Moving Collections that have Change Streams.

Unsharding a Collection

Starting in MongoDB 8.0, you can unshard existing sharded collections with the unshardCollection command or the sh.unshardCollection() method. This operation moves all documents in the collection onto a specified shard or the shard with the least amount of data.

For details, see Unsharded Collections. To get started, see Unshard a Collection.

Config Shards

Starting in MongoDB 8.0, you can configure a config server to store your application data in addition to the usual sharded cluster metadata. A mongod node that provides both config server and shard server functionality is called a config shard. A mongod node that runs as a standalone --configsvr without shard server functionality is called a dedicated config server.

To configure a dedicated config server to run as a config shard, run the transitionFromDedicatedConfigServer command.

To configure a config shard to run as a dedicated config server, run the transitionToDedicatedConfigServer command.

For details, see Config Shard. To get started, see Start a Sharded Cluster with a Config Shard. To convert a replica set to a sharded cluster with a config shard, see Convert a Replica Set to a Sharded Cluster with an Embedded Config Server.

New Database Commands

New mongosh Methods

serverStatus Metrics

Starting in MongoDB 8.0, serverStatus includes the following new shardingStatistics fields in its output:

MongoDB 7.1 includes the following new sharding statistics for chunk migrations:

Default Chunks Per Shard

Starting in MongoDB 7.2, when you shard an empty collection with a hashed shard key, the operation creates one chunk per shard by default. Previously, the operation created two chunks by default.

directShardOperations Role

Starting in MongoDB 8.0, you can use the directShardOperations role to perform maintenance operations that require you to execute commands directly against a shard.

Warning

Running commands using the directShardOperations role can cause your cluster to stop working correctly and may cause data corruption. Only use the directShardOperations role for maintenance purposes or under the guidance of MongoDB support. Once you are done performing maintenance operations, stop using the directShardOperations role.

dbhash Can Run Directly on a Shard

Starting in MongoDB 8.0.5, you can run dbHash directly on a shard. For a full list of shard direct commands, see Shard Direct Commands.

Exhaust Cursors Enabled for Sharded Clusters

Starting in MongoDB 7.1, mongos supports exhaust cursors when a client's getMore request sets the exhaustAllowed flag. This can improve query performance on sharded clusters when the client receives multiple replies from the database server for a single request.

mongos Port Range

Starting in MongoDB 7.1, mongos accepts --port values from [0, 65535]. For more information, see --port.

Query with Partial Shard Key

Starting in MongoDB 7.1, findAndModify and deleteOne() can use a partial shard key to query on a sharded collection.

Resharding Improvements

MongoDB 8.0 introduces significant performance improvements in resharding operations, substantially reducing the amount of time the operation takes to run.

Additionally, if your application and cluster meet the necessary requirements and limitations, you can reshard the collection on the same key using the reshardCollection command to redistribute your collection, which is much faster than alternative range migration procedure.

The following options are added to the command:

FieldDescription

forceRedistribution

Enables same-key resharding.

For examples, see Redistribute Data to New Shards.

Self-Managed Backups of Sharded Clusters

Starting in MongoDB 7.1, the fsync and fsyncUnlock commands can perform fsync operations on sharded clusters.

When run on mongos with the lock field set to true, the fsync command flushes writes from the storage layer to disk and locks each shard, preventing additional writes. The fsyncUnlock command can then be used to unlock the cluster.

This feature enables self-managed backups of sharded clusters using mongodump.

UpdateOne upsert Behavior on Sharded Collections

Starting in MongoDB 7.1, when using updateOne() with upsert: true on a sharded collection, you do not need to include the full shard key in the filter.

$lookup Stage in Transactions with Sharded Collections

Starting in MongoDB 8.0, you can use the $lookup stage within a transaction while targeting a sharded collection.

Replication

Majority Write Concern

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.

If your application reads from a secondary immediately after receiving an acknowledgment from a { w: "majority" } write operation (without a causally consistent session), the query may return results that don't include changes from the write.

New replSetGetStatus Metrics

Starting in MongoDB 8.0, the following metrics are available when using the replSetGetStatus command:

Oplog Buffers

Starting in MongoDB 8.0, secondaries write and apply oplog entries for each batch in parallel. A writer thread reads new entries from the primary and writes them to the local oplog. An applier thread asynchronously applies these changes to the local database. This changes increases replication throughput for secondaries.

This introduces a breaking change for metrics.repl.buffer, as it now provides metrics on two buffers instead of one.

MongoDB 8.0 deprecates the following server status metrics:

MongoDB 8.0 adds the following server status metrics:

Upgraded TCMalloc

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.

The new TCMalloc version directly impacts previous production recommendations for Transparent Huge Pages. To learn more, see TCMalloc Performance Optimization for a Self-Managed Deployment.

Tip

TCMalloc Compatibility Changes

serverStatus Metrics

Starting in MongoDB 8.0, the following new serverStatus metrics report information about tcmalloc usage:

General Changes

Shutdown Performance

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.

Store Application Data on Config Shards

Starting in MongoDB 8.0, you can configure a config server to store application data in addition to the usual sharded cluster metadata. The config server is then known as a config shard. For details, see Config Shards.

Compaction Improvements

Starting in MongoDB 7.3, the compact command includes a new freeSpaceTargetMB option to specify the minimum amount of storage space, in megabytes, that must be recoverable for compaction to proceed.

Background Compaction

Starting in MongoDB 8.0, you can use the new autoCompact command to perform background compaction. If enabled, the server attempts to keep free space within each collection and index below the specified the freeSpaceTargetMB value.

dryRun Option

If enabled, the compact command returns an estimate of how much space, in bytes, compaction can reclaim from the targeted collection. If you run compact with dryRun set to true, MongoDB only returns the estimated value and does not perform any kind of compaction.

Concurrent DDL Operations

Starting in MongoDB 7.1, when you run multiple DDL operations that target different collections from the same database, MongoDB runs those operations concurrently.

This change adds two new types to the serverStatus locks field and currentOp.locks output:

  • DDLDatabase
  • DDLCollection

Database Validation on mongos Aggregation Queries

Starting in MongoDB 7.2, aggregation pipeline queries that attempt to use non-existent databases on mongos deployments return validation errors.

In previous versions, these aggregation queries return empty cursors.

DDL Operations

In MongoDB 8.0, if you add or remove a shard while your cluster executes a DDL operation (operation that modifies a collection such as reshardCollection), any operation that adds or removes a shard only executes after the concurrent DDL operation finishes.

Error Codes for Exceeding Pipeline Size Limit

Starting in MongoDB 7.1, an aggregation command will throw an error when a pipeline exceeds the pipeline stage limit. For more details, see Number of Stages Restrictions.

getField Field Supports All Strings

Starting in MongoDB 7.2, you can specify any valid expression that resolves to a string for the field input of the $getField operator. In earlier versions, field accepts only string constants.

Improved Index Builds

Starting in MongoDB 7.1, index builds are improved with faster error reporting and increased failure resilience. You can also set the minimum available disk space required for index builds using the new indexBuildMinAvailableDiskSpaceMB parameter, which stops index builds if disk space is too low.

The following new index build metrics were added:

For full details, see Index Builds.

New Parameters

auditConfig Parameter

MongoDB 7.1 adds the auditConfig cluster parameter, which contains information on audit configurations from mongod and mongos server instances.

defaultMaxTimeMS Parameter

Starting in MongoDB 8.0, you can use the defaultMaxTimeMS cluster parameter to specify a default time limit for individual read operations to complete.

indexBuildMinAvailableDiskSpaceMB Parameter

MongoDB 7.1 adds the indexBuildMinAvailableDiskSpaceMB parameter, which allows you to set the minimum available disk space required for index builds.

tcmallocEnableBackgroundThread Parameter

Starting in MongoDB 8.0, the tcmallocEnableBackgroundThread is enabled by default. This allows MongoDB to periodically release memory back to the operating system.

New Query Shape and Query Settings

MongoDB 8.0 introduces a new query shape. The pre-existing query shape is renamed as the plan cache query shape.

Starting in MongoDB 8.0, you can add query settings for the new query shape. The query optimizer uses the query settings as an additional input during query planning, which affects the plan selected to run a query that has a matching query shape.

Query settings have improved functionality compared to index filters. Index filters are also deprecated starting in MongoDB 8.0, and you should avoid using them.

Starting in MongoDB 8.0, queryShapeHash is included in the following output:

Starting in MongoDB 8.0, the existing queryHash field is duplicated in a new field named planCacheShapeHash. If you're using an earlier MongoDB version, you'll only see the queryHash field. Future MongoDB versions will remove the deprecated queryHash field, and you'll need to use the planCacheShapeHash field instead.

numInitialChunks Option Removed

Starting in MongoDB 7.2, the numInitialChunks option is removed from the shardCollection command. The server automatically creates chunks on every shard in a cluster when using hashed sharding for an empty collection.

Parameter Filtering

Starting in MongoDB 8.0, the getParameter command accepts a setAt field. You can use this field to filter the allParameters: true return document to show only those parameters that you can set at startup or runtime.

Read Concern on Capped Collections

Starting in MongoDB 8.0, you can use read concern "snapshot" on capped collections.

serverStatus Output Change

Starting in MongoDB 7.1, the serverStatus command output includes the following new metrics:

Starting in MongoDB 7.2, the serverStatus command output includes the following new metrics:

Starting in MongoDB 7.3, the serverStatus command output includes the following new metrics:

Starting in MongoDB 8.0, the serverStatus command output includes the following new metrics:

Sort Option

Starting in MongoDB 8.0, updateOne(), replaceOne(), and update have an optional sort field to order documents before applying an update.

Previous releases use the findAndModify() and findOneAndUpdate() methods to update the first document in a user-specified sort order. Support for retryable writes requires these methods to copy the entire document to a special side collection for each node, which is a more expensive operation than the updateOne() method with the new sort option.

Specify Query Index Hints for distinct Commands

Starting in MongoDB 7.1, the hint field is available in the distinct command, allowing you to specify the query's index.

TTL Indexes

Starting in MongoDB 7.1, you can create TTL indexes on capped collections.

Query Planning and Execution

Express Query Stages

Starting in MongoDB 8.0, a limited set of queries (including _id equality matches) skip regular query planning and execution. Instead, these queries use an optimized index scan plan consisting of one of these plan stages:

  • EXPRESS_CLUSTERED_IXSCAN
  • EXPRESS_DELETE
  • EXPRESS_IXSCAN
  • EXPRESS_UPDATE

For more information on query plans, see Explain Results.

Rejected Query Plan Output

Starting in MongoDB 8.0, rejected query plans only contain the find portion of the query. In previous versions, rejected plans can contain aggregation stages like $group. Those aggregation stages aren't used by the query planner to choose the winning plan, so the rejectedPlans field only contains the portion of the query that was used to choose the winning plan.

This change also ensures that executionStats for rejected plans are non-zero. As a result, you can now see statistics such as how many documents or keys a rejected plan examined.

For more information on rejected query plans, see explain.queryPlanner.rejectedPlans.

Slot-Based Execution Engine Disabling

Starting in MongoDB 8.0, MongoDB automatically disables slot-based execution engine on collections with an index with a hashed path prefix of a non-hashed path, where both paths are in the index.

Batch Multi-Document Insert Operations

Starting in MongoDB 8.0, bulk insert operations outside of transactions may no longer produce individual oplog entries. Instead, MongoDB typically batches bulk inserts as a single entry. The change stream insert event for each document has the same clusterTime.

This change increases performance of multi-document insert operations and eliminates possible replication lag caused by multiple oplog writes.

OIDC Identity Providers Can Share an Issuer

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.

Namespaces in Subpipelines

Starting in MongoDB 8.0, namespaces in subpipelines inside $lookup and $unionWith are validated to ensure the correct use of from and coll fields.

For details, see $lookup subpipelines and $unionWith subpipelines.

Query Planner Optimization Time

The explain() method now returns information on query planner optimization time. The queryPlanner.optimizationTimeMillis status shows the time in milliseconds that the query planner spent on optimizations.

Upgrade Procedures

Important

Feature Compatibility Version

To upgrade to MongoDB 8.0 from a 7.0 deployment, the 7.0 deployment must have featureCompatibilityVersion set to 7.0. To check the version:

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

To upgrade to MongoDB 8.0, refer to the upgrade instructions specific to your MongoDB deployment:

If you need guidance on upgrading to 8.0, MongoDB professional services offer major version upgrade support to help ensure a smooth transition without interruption to your MongoDB application. To learn more, see MongoDB Consulting.

Download

To download MongoDB 8.0, go to the MongoDB Download Center.

Downgrade Considerations

Only Single-Version Downgrades are Supported

MongoDB only supports single-version downgrades. You cannot downgrade to a release that is multiple versions behind your current release.

For example, you can downgrade a 8.0-series to a 7.0-series deployment. However, further downgrading that 7.0-series deployment to a 6.0-series deployment is not supported.

Downgrade Policy

  • Binary downgrades aren't supported for MongoDB Community Edition.
  • You cannot downgrade your deployment's FCV to or from a rapid release version of MongoDB.
  • If you upgrade or downgrade your deployment's FCV, you cannot downgrade your Enterprise deployment's binary version without assistance from support.