Docs Menu

Docs HomeDevelop ApplicationsMongoDB Manual


On this page

  • Definition
  • Compatibility
  • Syntax
  • Behavior
  • Example


mongo Shell Method

This page documents a mongo method. This is not the documentation for database commands or language-specific drivers, such as Node.js. To use the database command, see the drop command.

For MongoDB API drivers, refer to the language-specific MongoDB driver documentation.

Removes a collection or view from the database. The method also removes any indexes associated with the dropped collection. The method provides a wrapper around the drop command.


For a sharded cluster, if you use db.collection.drop() and then create a new collection with the same name, you must either:

  • Flush the cached routing table on every mongos using flushRouterConfig.

  • Use db.collection.remove() to remove the existing documents and reuse the collection. Use this approach to avoid flushing the cache.

  • true when successfully drops a collection.
  • false when collection to drop does not exist.


When run on a sharded cluster, db.collection.drop() always returns true.

You can use db.collection.drop() for deployments hosted in the following environments:

  • MongoDB Atlas: The fully managed service for MongoDB deployments in the cloud

The drop() method has the following form:

db.collection.drop( { writeConcern: <document> } )

The drop() method takes an optional document with the following field:


Optional. A document expressing the write concern of the db.collection.drop() operation. Omit to use the default write concern.

When issued on a sharded cluster, mongos converts the write concern of the drop command and its helper db.collection.drop() to "majority".

  • The db.collection.drop() method and drop command create an invalidate for any Change Streams opened on dropped collection.

  • Starting in MongoDB 4.4, the db.collection.drop() method and drop command abort any in-progress index builds on the target collection before dropping the collection. Prior to MongoDB 4.4, attempting to drop a collection with in-progress index builds results in an error, and the collection is not dropped.

    For replica sets or shard replica sets, aborting an index on the primary does not simultaneously abort secondary index builds. MongoDB attempts to abort the in-progress builds for the specified indexes on the primary and if successful creates an associated abort oplog entry. Secondary members with replicated in-progress builds wait for a commit or abort oplog entry from the primary before either committing or aborting the index build.

  • Dropping a collection deletes its associated zone/tag ranges.

Changed in version 4.2.

db.collection.drop() obtains an exclusive lock on the specified collection for the duration of the operation. All subsequent operations on the collection must wait until db.collection.drop() releases the lock.

Prior to MongoDB 4.2, db.collection.drop() obtained an exclusive lock on the parent database, blocking all operations on the database and all its collections until the operation completed.

The following operation drops the students collection in the current database.


db.collection.drop() accepts an options document.

The following operation drops the students collection in the current database. The operation uses the "majority" write concern:

db.students.drop( { writeConcern: { w: "majority" } } )
← db.collection.distinct()