No, data is not immediately removed from disk after a delete operation in MongoDB. The WiredTiger storage engine performs a logical deletion by marking space as reusable, with physical removal occurring later through background processes or explicit commands.
When you delete documents in MongoDB using commands like deleteOne() or deleteMany(), the data is not immediately erased from disk. Instead, MongoDB performs a logical deletion: the documents are removed from the collection and no longer appear in query results, but their underlying disk space is simply marked as 'available for reuse' by the WiredTiger storage engine . This behavior is by design, optimized for write performance, and means the physical file size on your filesystem typically remains unchanged after a delete operation.
MongoDB's default WiredTiger engine manages disk space through sophisticated data structures. When data is deleted, the space it occupied is added to an internal 'available list' of reusable blocks . Future insert or update operations may write new data into these now-available blocks. This copy-on-write approach avoids expensive disk operations and fragmentation, but it also means that the operating system sees the file as the same size until those blocks are actually overwritten or the file is truncated . The disk space is only physically released back to the operating system under specific conditions, such as when a block at the very end of the file becomes free and is truncated during a checkpoint .
Dropping Collections/Databases: Commands like drop() or dropDatabase() delete the entire collection or database files. These operations remove the files from the filesystem entirely, immediately releasing the disk space back to the operating system .
Dropping Indexes: Similarly, dropIndexes removes the index file, which immediately frees the space it occupied .
If you need to reclaim disk space after deleting documents, you have several options. The compact command defragments the collection and attempts to reclaim unused space, though its behavior and locking characteristics vary by MongoDB version . For example, running db.runCommand({ compact: '<collection_name>' }) can free up space but may impact performance. Alternatively, you can use mongodump and mongorestore to rebuild the database with optimally packed data files . In replica sets, resynchronizing a member effectively rebuilds its data files from scratch, which also reclaims all deleted space .