MongoDB Upgrade Paths

Parent: MongoDB Expert Knowledge · Published reference · snapshot 2026-09-08 · skill mongodb-operations-expert/references/mongodb-upgrade-paths.md

↓ Facts as markdownall context files

Operational reference for MongoDB major-version upgrades on self-managed deployments. Covers the supported version sequence, Feature Compatibility Version (FCV) lifecycle, rolling replica-set and shar

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

MongoDB Upgrade Paths

When to use this skill

When NOT to use this skill

Related skills

1. Version upgrade paths

Hard rules

"Straight-to-8" jump pattern

Pre-flight: identify your starting version honestly

2. Feature Compatibility Version (FCV)

Key facts

Downgrade preservation window

Burn-in recommendation

3. Rolling upgrades — replica sets

Order

  • Stepping down is preferable to a hard shutdown because it triggers a clean election. Then upgrade the now-secondary former primary. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-upgrade-paths/#order]

    • Election timing

    Arbiter handling

    4. Sharded cluster upgrades

    Order (8.0 example, applies to every major hop)

    Version-skew rules

    Config shard caveat (8.0+)

    5. Driver compatibility

    Retry semantics

    Other drivers — quick rules

  • The canonical matrix lives at https://www.mongodb.com/docs/drivers/ - verify there for the exact patch level before any production upgrade. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-upgrade-paths/#other-drivers-quick-rules]

    • 6. Pre-upgrade checks

    Required gates

    Index builds and commit quorum (8.0 nuance)

    Binary downgrade window

    The "Point of No Return" command

    Practical rollback playbook

    8. Disk pre-warming (Cookie 7.0 → 8.0 lesson)

    The problem

    Why MongoDB docs don't cover it

    Pre-warming SOP (manual, customer-driven)

    Recommendation to MongoDB Engineering

    9. Upgrade event coverage

    Pre-event (T-7 days through T-0)

    During event (T-0 → T-end)

    Post-event (T-end → T+72 hours)

    Sign-off artefacts

    10. Common upgrade failures

    10.1 Driver mismatch

    10.2 FCV unpinned too early

    10.3 Index build conflicts

    10.4 mongos version skew

    10.5 PSA topology stepdown failure

    10.6 Oplog window overflow during long maintenance

    10.7 Cold-cache latency regression (Section 8)

    Sources

    Where this helps

    Project ideas

    Antipatterns

    Known issues

    Children

    Frontier under this node: Arbiter handling and PSA topology (4.28), Binary downgrade window (4.38), Change-stream resumability (4.08), Cold-cache latency regression (3.80), Common upgrade failures (3.40), Config server / shards / mongos upgrade sequence (3.92), Config shard caveat (8.0+) (2.58), Disk pre-warming SOP (Cookie 7.0→8.0 lesson) (4.00), Driver compatibility matrix (Java/Node/Python/.NET/Go) (4.28), Driver mismatch failure mode (3.98), Error Envelope and customer sign-off (2.50), FCV pinning and downgrade preservation window (4.30), FCV unpinned too early (4.30), In-flight index builds, Index build commit quorum (8.0 nuance), Index build conflicts, Java driver 4.10 and 5.x retry semantics (3.70), Oplog window overflow (4.25), Oplog window sizing (3.85), PSA topology stepdown failure (3.92), Point of No Return (3.48), Pre-upgrade safety checks (3.60), Rolling replica-set upgrade (4.08), Straight-to-8 jump pattern (3.45), Upgrade event coverage (pre/during/post) (3.02), Upgrade rollback playbook (3.75), Version upgrade paths (4.4 → 5.0 → 6.0 → 7.0 → 8.0) (3.70), WiredTiger cache warm-up (3.85), mongos version skew failure (3.92), mongos version skew rules (3.83)

    ← the whole tree · 3D view· how to read this page