Managing and Freeing Disk Space in MongoDB Deployments

MongoDB disk space problems usually show up in two ways: the filesystem is nearly full, or MongoDB appears large even after you deleted data. That second case surprises many teams because WiredTiger can reuse freed space internally without immediately returning it to the operating system.

Your goal is to tell the difference between real growth, reusable internal free space, oversized indexes, and fragmentation that needs a maintenance window.

Check Disk Usage at the Host Level

Start with the filesystem that contains MongoDB's dbPath. MongoDB cannot keep writing safely if that volume fills up.

df -h /var/lib/mongodb

Also check which directories are growing:

du -sh /var/lib/mongodb/* | sort -h

Use your actual dbPath; /var/lib/mongodb is common on Linux packages but not universal.

Check MongoDB Storage Metrics

Inside mongosh, compare logical data size with allocated storage size.

use myDatabase
db.stats()

Useful fields include:

• dataSize: Logical size of document data.
• storageSize: Space allocated for collection data.
• indexSize: Space used by indexes.

For a specific collection:

db.orders.stats({ scale: 1024 * 1024 })

Look at size, storageSize, and totalIndexSize. If storageSize is much larger than size, the collection may have reusable internal space from updates and deletes. If totalIndexSize is large, indexes may be the fastest place to reduce disk use.

Common Causes of MongoDB Disk Growth

High delete and update churn can leave internal free space inside WiredTiger files. MongoDB will often reuse that space for future writes, but the operating system may still show the files as large.

Indexes can also consume a large share of disk. Compound indexes, text indexes, wildcard indexes, and duplicate indexes add up quickly.

Retention gaps are another common cause. Log, session, event, and audit collections grow forever unless you archive or expire old documents.

Safe Ways to Reduce Future Growth

The best disk fix is usually preventing unbounded growth.

For time-based data, create a TTL index:

db.logEvents.createIndex(
  { createdAt: 1 },
  { expireAfterSeconds: 86400 }
)

TTL deletion is handled by a background monitor and is not instant to the second. It is still a good fit for logs, sessions, and temporary events where exact deletion timing is not critical.

Review indexes before dropping anything:

db.orders.getIndexes()
db.orders.aggregate([{ $indexStats: {} }])

$indexStats can show whether an index has been used since the process started. Treat that as a clue, not proof. A monthly report index may look unused on a quiet week.

Drop a confirmed unused index by name:

db.orders.dropIndex('customerId_1_createdAt_-1')

Reclaim Space from Existing Files

Deleting documents usually does not shrink WiredTiger files on disk. To return space to the filesystem, you need a rewrite or compaction strategy.

Use compact Carefully

compact can rewrite collection and index data to reduce disk use. It is resource intensive and may block operations on the affected collection, depending on your MongoDB version and deployment.

db.runCommand({ compact: 'orders' })

Run it during a maintenance window, test it first, and read the documentation for your exact MongoDB version. On replica sets, many teams compact one secondary at a time, let it catch up, and then step down or rotate members as needed.

Dump and Restore for Severe Fragmentation

For badly fragmented data, a dump-and-restore rebuilds the collection files cleanly. This is disruptive if you do it in place, so plan backups, downtime, or a replica-based migration.

mongodump --db myDatabase --collection orders --out /backup/mongo-dump

After you verify the dump and plan the cutover, restore into the target environment:

mongorestore --db myDatabase --collection orders \
  /backup/mongo-dump/myDatabase/orders.bson

Do not drop production data until you have a verified backup and a rollback plan.

What Not to Do

Do not delete WiredTiger, journal, or collection files manually from the filesystem. That can corrupt the database.

Do not assume du and MongoDB logical size should match. Compression, indexes, internal free space, and filesystem behavior all affect the numbers.

Be careful with old advice about MMAPv1-style preallocation. Modern MongoDB deployments typically use WiredTiger, and its storage behavior is different.

Practical Takeaway

When MongoDB disk use looks wrong, first measure the host, then measure databases, collections, and indexes. Use TTL indexes and archiving to slow growth. Drop only confirmed unnecessary indexes. For real filesystem reclamation, plan compact or a dump-and-restore workflow instead of expecting deletes to shrink files immediately.