Should I upgrade to MongoDB 7 to 8 now?
Plan MongoDB 7 to 8 rollouts around feature-compatibility-version changes and stricter downgrade constraints that materially affect rollback safety.
Blockers
- A 7.0 deployment must have featureCompatibilityVersion set to 7.0 before upgrading to MongoDB 8.0.
- Enabling featureCompatibilityVersion 8.0 requires running setFeatureCompatibilityVersion with 8.0 on MongoDB 8.0.
- Older 7.0 mongos instances can connect while FCV remains 7.0, but that stops after FCV moves to 8.0.
- Starting in MongoDB 8.0, direct command execution against shards is more restricted.
- Once FCV is upgraded to 8.0 and backward-incompatible persisted features are enabled, downgrade becomes materially more constrained and may require support assistance.
Who this is for
- enterprise
- high-scale
- compliance
Candidates
Two-phase rollout: upgrade binaries to 8.0 but hold FCV at 7.0 during burn-in
As of 2026-04-02, MongoDB requires a 7.0 deployment to have featureCompatibilityVersion set to "7.0" before upgrading to MongoDB 8.0. MongoDB's 8.0 upgrade docs state that you can run 8.0 binaries without enabling the 8.0 features that persist data incompatible with 7.0. MongoDB explicitly recommends a burn-in period before setting FCV to 8.0, because enabling backward-incompatible features makes downgrade harder. This is the safest rollout shape when rollback certainty matters more than immediate access to 8.0-only persisted features.
When to choose
Use this for enterprise or high-scale deployments where rollback safety is a release gate. It is the default choice when you need operational proof on 8.0 binaries before crossing the FCV line that narrows downgrade options.
Tradeoffs
Best rollback posture and lowest immediate compatibility risk, but you defer 8.0 persisted features until after burn-in. Teams must manage a temporary mixed state where binaries are 8.0 but FCV remains 7.0.
Cautions
On sharded clusters, once FCV is still 7.0, older 7.0 mongos instances can still connect, but that stops after FCV moves to 8.0. If you later need to downgrade, MongoDB says to downgrade to the latest 7.0 patch release, not an older major.
Enable FCV 8.0 soon after upgrade and accept support-gated downgrade
As of 2026-04-02, enabling MongoDB 8.0's backward-incompatible persisted features requires running setFeatureCompatibilityVersion with "8.0" and confirm: true. MongoDB documents that once you upgrade or downgrade FCV, binary downgrade requires support assistance, and MongoDB Community Edition does not support binary downgrades. MongoDB also warns that if incompatible data exists during FCV downgrade, the cluster can return CannotDowngrade and remain in a transitional downgrading state until you remove the incompatible features or restore the original FCV. This path is appropriate only when the team is willing to treat FCV 8.0 as the practical end of self-serve rollback.
When to choose
Use this when 8.0-only persisted features are required quickly and the organization already operates with support-backed rollback or blue-green replacement instead of binary rollback. The decisive factor is whether you can tolerate support involvement and cleanup work if you must reverse course.
Tradeoffs
You unlock full 8.0 capability sooner, but rollback becomes materially more constrained. Operationally, this shifts recovery planning away from quick downgrade and toward restore, failover, or parallel-cluster strategies.
Cautions
For sharded clusters, setting FCV to 8.0 implicitly performs replSetReconfig on each shard, waits for majority propagation, and can cause chunk migrations, splits, and merges to fail with ConflictingOperationInProgress while the command runs. Starting in MongoDB 8.0, direct command execution against shards is also more restricted, which can break older maintenance habits during incident response.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Should I upgrade to MongoDB 7 to 8 now?"