Reclaiming MongoDB Storage Space: A Journey to 50% Space Reduction

Efficiently Reclaim Disk Space in MongoDB: Strategies and Solutions for Optimal Performance.

Thivakar November 03, 2026

Architecture of the MongoDB setup
Before Optimization
After Optimization
Key Actions Taken
Architecture of the MongoDB setup after adding temporary node
IP Swap process
Results
Best Practices for Ongoing Optimization

Subscribe for email updates

Summarize with AI: ChatGPT Google AI Perplexity Claude Grok

FAQ

The main cause was fragmented data. Over time, deletes and updates leave unused space inside the data files, and MongoDB does not always return that space to the operating system. The files kept growing while much of that space sat unused, so all three nodes showed 92% usage on 2TB disks.

In MongoDB 4.0.3, the compact operation blocks operations on the database it is running against and takes a long time on large collections. That means significant downtime. It also has to run on each node separately. Because of these limitations, we chose a safer approach that kept the application available.

A hidden node is a replica set member that holds a full copy of the data but is invisible to applications. It cannot become primary, and clients do not read from it. We added a new hidden node and let it perform an initial sync. An initial sync copies the data into fresh files, so the data arrives defragmented and takes much less space. The existing nodes kept serving traffic the whole time.

Applications could not be re-pointed between nodes, so we swapped IP addresses instead. We stopped MongoDB on the new node and on the secondary being replaced, swapped their IPs, and restarted both services. The application kept connecting to the same IP and reached the optimized node without any configuration change. The only interruption was the short restart window.

Initial sync on a large dataset takes a long time, so temporary network errors can interrupt it. On an older version like 4.0.3, a sync that hits such an error can fail. We handled this by increasing the initialSyncTransientErrorRetryPeriodSeconds parameter, which lets the sync keep retrying through transient errors instead of failing. Using a hidden node also meant the long sync did not affect production traffic.