MongoDB EOL: MongoDB End of Life Dates by Version

MongoDB 4.2 reached end of life on 30 April 2023, 4.4 on 29 February 2024, 5.0 on 31 October 2024 and 6.0 on 31 July 2025. MongoDB 7.0 is supported until 31 August 2027, 8.0 until 31 October 2029 and 9.0, released in September 2026, until 31 October 2031. A version past its end of life date no longer receives fixes from MongoDB, security fixes included.

The dates below come from MongoDB's Software Lifecycle Schedules, checked on 12 October 2026. The same server dates apply to Community Server, Enterprise Advanced and Atlas Dedicated. What changes is the consequence of the date, which depends on how you run MongoDB.

MongoDB's end of life policy, in its own words

MongoDB's versioning page says major releases arrive about every two years and carry a five-year lifecycle, but the dates on the lifecycle schedule are what count (7.0's is a year shorter). The Software Support Policy is blunt about what follows: MongoDB has no obligation to provide support if you are running a version that has passed its end of life date. The schedule adds a rule that catches application teams: drivers released more than three years after a server version's end of life date will not be compatible with that server version.

MongoDB end of life dates by version

Source: MongoDB Software Lifecycle Schedules. 7.0 has less than a year left, so moving 6.0 to 7.0 only buys time; aim at 8.0 or 9.0. Minor releases such as 8.2, which ended on 31 July 2026, are a separate track: MongoDB stops patching the previous minor when a new one ships.

Community, Enterprise Advanced and Atlas: same dates, different consequences

• Community Server. There is no vendor support contract, so end of life simply means the fixes stop.
• Enterprise Advanced. The subscription covers versions inside their lifecycle. MongoDB's versions page describes an optional two-year Extended Lifecycle Support period for Enterprise Advanced customers, bought as an add-on. Ops Manager has its own schedule: 7.0 ended on 28 February 2026 and 8.0 runs to 31 October 2027.
• Atlas. MongoDB patches the service, and Atlas Dedicated clusters use the same end dates for 5.0 to 9.0. If you stay on a major version you must upgrade it yourself before end of life. MongoDB notifies you of the cut-off date, and after it Atlas upgrades the cluster to its current default target version, which the versions page warns is not always the next major version. Atlas upgrades one major version at a time, so a forced upgrade lands on MongoDB's calendar, not yours.

Why upgrading off 4.x, 5.0 and 6.0 is hard

MongoDB does not let you skip a major version. To reach 9.0 you must be running 8.0 or 8.3, to reach 8.0 you must be on 7.0, and the same rule holds all the way back. From 4.4 that is five full upgrades of every replica set and sharded cluster, each a binary change followed by raising featureCompatibilityVersion. While the FCV stays at the old value you can still roll back, which is the window to test in.

Two things stop teams before they start. The first is hardware: 5.0 and later require the AVX instruction set on x86_64, and some virtual machine CPU models do not expose it, so a guest that ran 4.4 happily cannot run 5.0 until the CPU model changes. The second is drivers. Check both before planning anything:

# MongoDB 5.0+ on x86_64 needs AVX. Empty output means this host cannot run it.
grep -o -m1 '\bavx\b' /proc/cpuinfo
# server version and feature compatibility version
mongosh --quiet --eval 'db.version()'
mongosh --quiet --eval 'db.adminCommand({getParameter:1, featureCompatibilityVersion:1})'

The driver compatibility tables show the same drift from the other side. Node.js driver 7.6 and 7.7, for example, no longer list MongoDB 4.2, while 7.3 to 7.5 still do. Take a backup you have actually restored before the first step; our MongoDB backup guide covers how, and the MongoDB migration guide covers moving between versions and platforms.

What running an end-of-life MongoDB version risks

• Security fixes are discretionary. CVE-2025-14847, nicknamed MongoBleed, lets an unauthenticated client read uninitialized heap memory through mismatched length fields in zlib-compressed protocol headers. It was published on 19 December 2025, scores 7.5, and was added to CISA's Known Exploited Vulnerabilities catalogue on 29 December 2025. MongoDB released fixes for 4.4.30, 5.0.32 and 6.0.27, all already end of life, but the NVD record lists 4.2, 4.0 and 3.6 as affected with no fixed version. A courtesy fix is not a commitment.
• No support obligation. Under the policy above MongoDB can decline a ticket on 5.0.
• Drivers move on. New driver releases stop listing old servers, and the three-year rule makes the break formal.
• Audits flag it. An unsupported database is a finding in most frameworks.

The incidents that show up on older MongoDB clusters

• A secondary that cannot catch up. A member that is disconnected for longer than the oplog window can no longer sync by replication and needs a full resync. A small oplog shortens that window. See replica set and oplog support.
• Cache pressure and stalls. WiredTiger throttles application threads once the cache, or its share of dirty data, crosses an eviction trigger, and operations stall when the cache is full. The symptom is latency that climbs with write load. See WiredTiger eviction remediation.
• Server and driver drift. A new application build pulls in a driver that no longer lists your server version, and the failure shows up in production, not in the build.

None of these is caused by end of life. What end of life changes is that if the cause is a server defect, the fix will not ship for your version.

Your options for a MongoDB version past end of life

• Keep the version you run, and keep it patched. OSSeva, AceMQ's extended support platform, provides patched builds of self-managed MongoDB Community Server 4.2, 4.4, 5.0 and 6.0 after MongoDB's end of life, with security coverage committed under contract, signed artifacts and SBOMs. It includes 4.2 and 4.4 builds for hardware without AVX. It does not cover Atlas, which MongoDB patches itself. This is the first option to look at when the upgrade cannot run this quarter.
• Upgrade to 8.0 or 9.0. The right end state, taken one major version at a time. Rehearse each step on a copy, check drivers, and keep a restorable backup.
• Move to Atlas or buy vendor cover. Atlas takes patching off you in exchange for MongoDB's calendar and its pricing; see MongoDB Atlas pricing. Enterprise Advanced with the Extended Lifecycle Support add-on is MongoDB's own answer for a version past end of life.
• Put an operations team behind it. Patches close the vulnerability gap; they do not answer the phone when a primary stops stepping up. AceMQ provides 24/7 MongoDB support for Community, Enterprise Advanced and Atlas on any version, with a 15-minute emergency SLA, and plans the upgrade with you. For how vendor, community and independent support compare, see MongoDB support options.

Start with an inventory: run db.version() on every mongod and mongos, record the FCV, and list the drivers each application uses. That decides which option is realistic. For the other technologies AceMQ and OSSeva cover past end of life, see end-of-life software support and database support.

• MongoDB: Software Lifecycle Schedules
• MongoDB: Software Support Policy
• MongoDB: Cloud Services Support Policy
• MongoDB Manual: MongoDB Versioning
• MongoDB Docs: Versions and Upgrade Paths
• MongoDB Atlas: MongoDB Versions in Atlas
• MongoDB Atlas: Upgrade Major MongoDB Version for a Cluster
• MongoDB Manual: Upgrade 8.3 Replica Set to 9.0
• MongoDB Manual: Upgrade a Replica Set to 8.0
• MongoDB Manual v5.0: Upgrade a Replica Set to 5.0
• MongoDB Manual: Production Notes (AVX requirement)
• MongoDB Docs: Client Library Compatibility Tables
• MongoDB Manual: Replica Set Oplog
• WiredTiger: Cache and eviction tuning
• NVD: CVE-2025-14847
• CISA: Known Exploited Vulnerabilities Catalog entry for CVE-2025-14847
• MongoDB: Extended Lifecycle Support Add-On
• OSSeva: MongoDB extended support