As MongoDB has matured over the past 15+ years, new major versions bring impactful enhancements like multi-document transactions, native time-series support, distributed transactions, and more. However, to leverage these capabilities you first need to verify your current MongoDB version.
This in-depth guide covers multiple methods to check the database version from CLI tools, the graphical UI, and programmatically from inside applications. Read on to learn how!
A Brief History of MongoDB Versions
Since its initial release in 2009, MongoDB has steadily improved performance, scalability, security, and ease of use with each major release:
- v1.0 (2009) – Initial stable GA release
- v2.0 (2013) – MMAPv1 storage engine, index build improvements
- v2.4 (2015) – WiredTiger storage engine
- v2.6 (2016) – Encrypted connections
- v3.0 (2016) – Document validation
- v3.2 (2017) – Change streams
- v3.4 (2018) – Multi-document ACID transactions
- v4.0 (2019) – Distributed ACID transactions
- v4.2 (2020) – Data lake with MongoDB Atlas
- v4.4 (2020) – Serverless databases with MongoDB Realm becoming generally available
- v5.0 (2021) – Time-series collections and zstandard compression
Reviewing the release notes shows impressive growth in capabilities over seven major releases so far.
But to leverage this progress, confirming your installed MongoDB version is crucial.
Why Version Matters for Security
Beyond access to new features, from my experience leading production MongoDB deployments, staying current with the latest stable version improves:
- Security – Critical patches get backported to older releases but upgrading simplifies verification
- Compliance – New encryption, auditing, and authorization features may be required
- Support – Public cloud vendors certify and patch specific MongoDB releases
Consider these MongoDB security enhancements over the years:
- Native SSL/TLS support added in v2.6 (2016)
- Client certificate validation required in v4.2 (2020)
- AES-GCM encryption standard enabled in v4.2
- Role-based access control refinements in v4.0
Reviewing security best practices guides like this checklist shows many depend on recent releases.
While specific fixes may get back-ported, staying current following the shared responsibility model minimizes exposure to vulnerabilities.
MongoDB Market Share and Growth
To measure the popularity of MongoDB, DB-Engines tracks database management system adoption based on number of mentions across sites like Stack Overflow and social media. This acts as a proxy for usage.
MongoDB has ranked in the top 5 most popular databases since 2013. As of January 2023, it stands firm as the #4 database behind Oracle, MySQL, and Microsoft SQL Server:
Image from DB-Engines
DB-Engines also shares a graph of MongoDB‘s rapid growth in popularity over the past decade:
Image from DB-Engines
With over 35 million downloads and usage across major cloud providers like AWS, Azure, and GCP – MongoDB sits firmly among the eliteopen source databases.
But with growth comes a responsibility to "leave no DB behind" through maintaining compatibility across versions.
Impacts of Compatibility Across the Stack
While compelling new functionality ships with each release, MongoDB balances innovation with stringent backwards compatibility guarantees within major versions.
For example, MongoDB 4.2 supports drivers and applications built for 4.0 without issue. But upgrading from 3.6 to 4.0 requires adaptations.
This allows upgrading the database version without heavily modifying the application logic itself. Backwards compatibility enables easier adoption of new capabilities.
However several key dependencies still require lockstep version checking:
MongoDB Drivers
Image from MongoDB Drivers
- MongoDB drivers maintain compatibility with only the latest 1 or 2 stable releases
- Supporting older MongoDB versions takes significant resources
- Drivers often expose new CRUD APIs matching database capabilities
For example, MongoDB added multi-document ACID support in v4.0. To leverage these transactions in Node.js, upgrading from the v3 driver to v4 aligned the APIs.
Cloud Environments
Major public clouds support specific MongoDB versions:
| Platform | Versions |
|---|---|
| MongoDB Atlas | 4.2, 4.4, 5.0 |
| AWS DocumentDB | 3.6, 4.0 |
| Azure CosmosDB | 3.2, 3.6, 4.0, 4.2 |
| GCP Firestore | Datastore mode |
PaaS services take time qualifying each release before making available on their platforms.
Staying up-to-date reduces divergence between your on-prem or self-managed cluster version vs. hosted solutions. This eases potential future migrations to the cloud.
Open Source Libraries
Tools in the wider open source ecosystem also maintain compatibility with MongoDB releases:
| Library | Supported Versions |
|---|---|
| Mongoose (Node.js) | 3.6+, 4.0+ |
| PyMongo (Python) | 3.0+, 4.0+ |
| Morphia (Java) | 3.2+, 3.4+ |
These ODMS and modeling libraries simplify interacting with MongoDB from application code. Tracking which releases they run against prevents unexpected issues.
With so many interdependent moving pieces – double checking your current MongoDB version helps avoid surprises down the line!
Best Practices for MongoDB Upgrades
Now that we‘ve covered why you should keep MongoDB versions current, let‘s discuss best practices how to actually upgrade guided by MongoDB‘s recommendations:
1. Review Upgrade Considerations
- Assess custom schema constructs for compatibility via validation
- Check dependent library and platform matrixes
- Consider security requirements of target version
2. Test Existing Workloads
- Replay representative production data on new version
- Put applications through simulation testing
- Profile for performance regressions
3. Plan Maintenance Window
- Schedule downgrade window if issues emerge
- Select change window with lowest traffic
- Implement temporary read scaling to sustain traffic
4. Upgrade Cluster Members
- Drain and upgrade secondaries first
- Set Cluster to read-only during upgrade
- Upgrade the primary last
5. Update Drivers
- Release drivers with compatibility fixes
- Roll upgraded clients into production
6. Verify Monitoring and Alerts
- Check key operational metrics post-upgrade
- Tun e thresholds as needed
Following these steps and checking the current version minimizes disruption for production upgrades.
Alright – with the context out of the way, let‘s dig into how to check MongoDB versions using various methods!
MongoDB Version Checking Methods
There are a handful of convenient ways to check the currently installed version of the MongoDB database.
Here I‘ll cover the options:
- The
mongod --versionCommand - The
mongo --versionCommand - The
db.version()Method - The
db.runCommand({ buildInfo: 1 })Command - The MongoDB Compass GUI
- Checking Version from Application Code
Let‘s explore each approach to find your MongoDB version in more detail.
1. The mongod --version Command
The easiest way to check the MongoDB version from the command line is by using the mongod --version command.
mongod represents the primary MongoDB database server process. By passing the --version flag, it will print out the version and additional build details:
mongod --version
db version v5.0.14
Build Info: {
"version": "5.0.14",
"gitVersion": "187bd1a32de34d1a7316364fd654140d09eebf8a",
...
}This quickly prints the major, minor, and patch release number. Extra info like the Git commit hash tracks the exact code snapshot from GitHub used.
This method does not require having a MongoDB instance currently running or connecting via the Mongo shell. It reports the mongod binary version available on your system‘s PATH.
2. The mongo --version Command
Similar to checking the database daemon itself, you can also verify the installed version of the MongoDB command shell using:
mongo --version
MongoDB shell version v5.0.14
...
```
The shell provides an interactive JavaScript interface to connect and work with MongoDB.
While the database and shell releases typically match, calling `mongo --version` definitively confirms the shell version. This proves important for testing any shell API changes impacting scripts or automation relying on specific releases.
### 3. The `db.version()` Method
Once you have a MongoDB instance running and can connect into it with the Mongo shell, you can directly query the database version using:
```js
> mongo
> db.version()
5.0.14
```
The `db.version()` method returns the precise database version as a simple string.
This option works great if you have a remote MongoDB server running and want to quickly check the exact version from the JS shell.
No need to dig through logs or the filesystem to determine release details - just ask the `db` itself!
### 4. The `db.runCommand({ buildInfo: 1 })` Command
Similar to `db.version()`, this Mongo shell approach requires an established connection to a running MongoDB database.
You can use the [`buildInfo`](https://www.mongodb.com/docs/manual/reference/command/buildInfo/) command to return rich meta data around version:
```js
> db.runCommand({ buildInfo: 1 })
{
"version" : "5.0.14",
"gitVersion" : "187bd1a32de34d1a7316364fd654140d09eebf8a",
"modules" : [ ],
"allocator" : "tcmalloc",
...
}
```
It exposes release number alongside platform details, compiled modules in use, SSL availability, and more.
As a pro tip, if you ever need to collect information about the underlying system MongoDB runs on - `buildInfo` should be your first stop.
### 5. The MongoDB Compass GUI
When working in the MongoDB Compass administration UI, the About dialog prints the release version:
Likewise in the web-based Ops Manager or Cloud Manager consoles, the version displays front and center on settings and deployment views.
Graphical tools provide convenient point-and-click access to look up the database version without fussing with command lines.
### 6. Checking Version from Application Code
In MongoDB applications written in Node.js, Python, Java, C#, Go and other languages - you may want to programmatically access database metadata.
For example, to show users which MongoDB version powers your app or keep an audit trail of upgrades.
Most official MongoDB drivers provide a clear path to lookup the connected version number:
**Node.js**
```js
const { MongoClient } = require(‘mongodb‘)
async function printVersion(uri) {
const client = new MongoClient(uri);
try {
await client.connect()
const result = await client.db().command({ buildInfo: 1 })
console.log(result.version)
} catch (err) {
console.log(err)
} finally {
client.close()
}
}
printVersion(‘mongodb://localhost:27017‘)
```
This queries the `buildInfo` command and prints the `version` field from the document result.
**Python**
```python
import pymongo
my_client = pymongo.MongoClient("mongodb://localhost:27017/")
my_db = my_client[‘mydatabase‘]
version = my_client.server_info()[‘version‘]
print(f"Connected MongoDB Version: {version}")
```
Uses handy `server_info` helper and the `version` field to fetch release details.
**Java**
```java
import com.mongodb.client.*;
public class VersionChecker {
public static void main(String[] args) {
MongoClient mongoClient = MongoClients.create("mongodb://localhost");
MongoDatabase database = mongoClient.getDatabase("mydb");
String version = database.runCommand(new Document("buildInfo", 1))
.getString("version");
System.out.println(version);
mongoClient.close();
}
}
```
Familiar `buildInfo` command invoked on database instance prints connected MongoDB version.
This makes displaying the running database release alongside an application‘s own version simple.
No matter which language powers your stack - checking MongoDB‘s version programmatically integrates neatly.
## Conclusion
Understanding techniques to validate your MongoDB version provides awareness of available capabilities, compatibility with other components, and security posture.
We covered several easy approaches to check the database release - ranging from command line utilities like `mongod`, the interactive shell, MongoDB Compass, and even calling meta commands right from application code itself.
Hopefully this guide gave you the tools to verify which MongoDB version runs underneath your applications with minimal fuss!
Keeping your databases updated fueled by robust processes unleashes next-generation features and drives operational excellence. Identifying the current versions running acts as the crucial first step to upgrades powering innovation.