MongoDB tools you should know: best practices explained

After months of building production systems, you've learned that MongoDB's flexibility is both a strength and a trap. The database itself works, but without the right tools, you're flying blind through query performance, backup procedures, and schema validation. MongoDB tools you should know will transform how your team debugs, optimizes, and maintains data across development, staging, and production environments.

mongosh for scripting and bulk operations

mongosh is the modern MongoDB shell, replacing the legacy mongo shell. It's essential for any engineer who needs to move beyond the GUI and automate tasks, run complex queries, or perform bulk data modifications. Unlike point-and-click interfaces, mongosh lets you write repeatable scripts that integrate into your deployment pipeline.

The most common production use case is bulk updates. Imagine you need to migrate a field structure across millions of documents. With mongosh, you can write a script that runs incrementally, checks for errors, and logs progress:

// Connect to your database
const db = db.getSiblingDB('your_database');

// Bulk update with error handling
const collection = db.users;
let processed = 0;
let errors = 0;

collection.find({ 'profile.type': { $exists: false } }).forEach(doc => {
  try {
    collection.updateOne(
      { _id: doc._id },
      {
        $set: { 'profile.type': 'standard' },
        $currentDate: { updatedAt: true }
      }
    );
    processed++;
  } catch (e) {
    errors++;
    print(`Error updating ${doc._id}: ${e.message}`);
  }
  
  if (processed % 10000 === 0) {
    print(`Processed: ${processed}, Errors: ${errors}`);
  }
});

print(`Complete. Processed: ${processed}, Errors: ${errors}`);

Save this as migrate.js and run it with mongosh your_connection_string --file migrate.js. This approach is faster and safer than doing ad-hoc updates through an ORM, and you have a repeatable record of what changed.

Another critical use of mongosh is index management. You can list all indexes on a collection, check their sizes, and identify duplicates or unused indexes that bloat your storage:

db.orders.getIndexes();

The output shows you exactly which indexes exist, their key specification, and options like uniqueness. In production systems we've worked on, teams often accumulate duplicate indexes without realizing it, consuming memory and slowing down writes.

Compass for visual queries and index exploration

MongoDB Compass is the GUI tool that bridges the gap between SQL developers and document databases. If you're used to SQL clients like pgAdmin or DBeaver, Compass provides a similar experience but designed for MongoDB's schema flexibility.

The primary value is visual query building and real-time result inspection. Instead of typing query syntax from memory, you can use form controls to construct filters, projections, and aggregations, then export them as code:

A real-world scenario: a new team member joins and needs to understand the product data model. Instead of reading documentation (which is always out of date), they open Compass, browse collections, and see actual field names, data types, and sample values. They click on a few documents and immediately grasp the structure.

Compass also includes an Index tab that visualizes index performance. You can see which fields are indexed, their size, and whether an index is being used by your queries. This visual feedback is invaluable when troubleshooting slow operations. The Explain Plan feature shows execution stats for any query you run:

// In Compass, after running a query, click "Explain Plan" to see:
// - Number of documents scanned
// - Number of documents returned
// - Whether an index was used
// - Execution time

For teams that haven't invested in APM tools yet, Compass provides a lightweight way to spot bottlenecks.

mongodump and mongorestore for backups and data migration

mongodump and mongorestore are the workhorses for backups and environment-to-environment data transfers. While MongoDB Atlas provides automated backups, we've found that teams need local control over snapshots for several reasons: copying data to staging for bug reproduction, creating sanitized datasets for development, or migrating between clusters.

Basic dump syntax:

// Backup entire database
mongodump --uri "mongodb://user:pass@host:27017/production_db" --out ./backup

// Backup specific collection
mongodump --uri "mongodb://user:pass@host:27017/production_db" \
  --collection orders --out ./backup

// Compress the output
mongodump --uri "mongodb://user:pass@host:27017/production_db" --archive=backup.archive --gzip

The compressed archive approach is critical for production: it reduces network transfer time and storage footprint. A typical e-commerce database with 50GB of data becomes 8-12GB when compressed.

Restoration is equally straightforward:

// Restore from compressed archive
mongorestore --uri "mongodb://user:pass@localhost:27017/dev_db" \
  --archive=backup.archive --gzip

// Restore specific collection
mongorestore --uri "mongodb://user:pass@localhost:27017/dev_db" \
  --collection orders ./backup/production_db/orders.bson

One best practice we've learned: always test your restore process. Teams sometimes discover, months later, that their backup strategy doesn't work when they actually need it. Schedule periodic restore drills to a staging database.

For large datasets, consider using --numParallelCollections to speed up the restore:

mongorestore --uri "mongodb://..." --archive=backup.archive --gzip --numParallelCollections 4

Atlas Performance Advisor for production optimization

If you're running MongoDB on Atlas (the managed cloud service), the Performance Advisor is a tool that shouldn't be ignored. It continuously analyzes your queries and indexes, then recommends improvements. Think of it as a code review bot for your database.

The Advisor identifies three common issues:

1. Slow queries without indexes: Flags queries that scan many documents without matching the query selectivity. This often means you need an index on the filter fields.
2. Redundant indexes: Detects indexes that duplicate coverage of other indexes, wasting space and slowing writes.
3. Unused indexes: Shows indexes that exist but aren't used by any queries in the recent window.

In a production ride-hailing system we worked on, the Advisor flagged that the location query was being run without a geospatial index. After adding the index, query time dropped from 800ms to 12ms. This kind of visibility is invaluable and saves you from firefighting performance issues in production.

The Advisor also samples slow queries (those exceeding a configurable threshold, default 100ms), so you have concrete data on which operations are bottlenecks. You can then prioritize index creation or query optimization based on real usage patterns.

One caveat: the Advisor requires 24+ hours of query data to generate recommendations. On day one of a new cluster, it has nothing to suggest. But after a week of normal traffic, you'll have actionable insights.

Common mistakes

• Skipping index creation and relying on query optimization alone: New teams often assume their ORM or application layer will handle performance. Without proper indexes, even well-written code bogs down under load. Use Compass or Atlas Advisor to identify missing indexes early.
• Treating mongodump as a real-time backup strategy: Snapshots are point-in-time and can be minutes or hours old. For systems requiring RPO measured in seconds, you need MongoDB's oplog replication or Atlas continuous backups, not just periodic dumps.
• Running bulk updates without pagination: Loading millions of documents into memory with .forEach() can crash the shell. Always paginate: process 10,000 documents, commit, then fetch the next batch.
• Ignoring Compass's schema validation pane: Teams struggle to understand their data, then spend hours writing queries that could have been avoided by inspecting actual document examples in Compass.
• Granting too many Atlas Advisor recommendations without testing: Sometimes the Advisor suggests indexes that help one query but hurt another. Always test changes on staging first.

Key takeaways

• mongosh is for automation and repeatability: write scripts for bulk operations, index management, and migrations that you can version control and rerun.
• Compass is for exploration and understanding: use it to visualize queries, inspect schema, and explain slow operations without writing syntax from memory.
• mongodump/mongorestore are for snapshots and transfers: compress large backups, test restores regularly, and use them for moving data between environments safely.
• Atlas Performance Advisor is your continuous performance auditor: review recommendations weekly and prioritize index creation based on real query patterns.
• Combine tools for maximum efficiency: use Compass to build queries, export them to mongosh for scripting, monitor with the Advisor, and back up with dumps. No single tool replaces the others.