MongoDB Release Model - Rapid Releases and Major Version Support

MongoDB runs two release tracks at once. Major versions arrive roughly annually and are the ones supported for self-managed deployments over several years. Rapid releases appear quarterly and deliver features earlier, primarily to Atlas. Between them sits the feature compatibility version setting, which decouples the binaries you run from the feature set you enable - and which is the key to safe upgrades and to being able to roll back.

Two tracks, one product

MongoDB publishes on two cadences:

Rapid releases are numbered as minor increments but behave like previews of the next major. They are not given long support windows for self-managed use; the features in them are consolidated into the next major version, which is the one you standardise on.

For most self-managed installations the practical rule is to ignore the rapid releases and track the major versions.

Support windows

Major versions receive support for a period measured in years after general availability, with the exact dates published per version. Patch releases within a major (8.0.1, 8.0.2) carry bug and security fixes and are safe to apply.

Because the support window is only a few years, MongoDB upgrades come around noticeably more often than they do for, say, PostgreSQL. Building a routine for them matters more than it does elsewhere.

Feature compatibility version

The most important operational concept in a MongoDB upgrade is featureCompatibilityVersion (FCV). It separates the binaries you are running from the feature set that is active.

When you upgrade binaries from 7.0 to 8.0, FCV stays at 7.0 until you raise it explicitly:

db.adminCommand({ setFeatureCompatibilityVersion: "8.0", confirm: true })

While FCV remains at the old value, new persistent features are not enabled and you can downgrade the binaries cleanly. Once FCV is raised, the data files may use structures the older version cannot read, and downgrade becomes far harder.

The sequence that follows from this is:

1. Upgrade binaries across the replica set, secondaries first, then step down and upgrade the primary.
2. Run at the new binaries with the old FCV long enough to be confident - days, not minutes.
3. Raise FCV.

Skipping step two is the most common way a MongoDB upgrade goes wrong, because it removes the rollback option exactly when you might need it.

Upgrading through majors

MongoDB does not support skipping major versions. Moving from 6.0 to 8.0 means going through 7.0, including raising FCV at each step. Falling several majors behind therefore turns one upgrade into a chain of them, which is a strong argument for staying reasonably current.

Sharded clusters have their own ordering: config servers, then shards, then mongos routers, with the balancer stopped for parts of the process.

Driver compatibility

Drivers have their own compatibility matrices. A driver generally supports several server versions, but the reverse is not always true - a very old driver may not support a new server, particularly where authentication or wire protocol changes are involved. Check the driver matrix before the server upgrade, not after.

Recent direction

Recent major versions have focused on throughput and operational behaviour rather than new query surface: improvements to the query engine and aggregation execution, better time series collection handling, queryable encryption, and reductions in replication and resharding overhead.

Conclusion

MongoDB’s model is an annual major version for people running their own clusters and quarterly rapid releases for those on Atlas. The support window of a few years per major means upgrades are a regular event rather than a rare one. Learn the feature compatibility version mechanism, use the gap between upgrading binaries and raising FCV as your safety margin, and never plan to skip a major version.