create

Optional. The name of the field which contains metadata in each time series document. The metadata in the specified field should be data that is used to label a unique series of documents. The metadata should rarely, if ever, change The name of the specified field may not be _id or the same as the timeseries.timeField. The field can be of any data type.

Although the metaField field is optional, using metadata can improve query optimization. For example, MongoDB automatically creates a compound index on the metaField and timeField fields for new collections. If you do not provide a value for this field, the data is bucketed solely based on time.

Optional, do not use if setting bucketRoundingSeconds and bucketMaxSpanSeconds. Possible values are seconds (default), minutes, and hours.

Set granularity to the value that most closely matches the time between consecutive incoming timestamps. This improves performance by optimizing how MongoDB internally stores data in the collection.

For more information on granularity and bucket intervals, see Set Granularity for Time Series Data.

Optional, used with bucketRoundingSeconds as an alternative to granularity. Sets the maximum time between timestamps in the same bucket. Possible values are 1-31536000. If you set bucketMaxSpanSeconds, you must set bucketRoundingSeconds to the same value.

To downgrade below MongoDB 6.3, you must either modify the collection to use the corresponding granularity value, or drop the collection. For details, see collMod.

Optional, used with bucketMaxSpanSeconds as an alternative to granularity. Sets the number of seconds to round down by when MongoDB sets the minimum timestamp for a new bucket. Must be equal to bucketMaxSpanSeconds

For example, setting both parameters to 1800 rounds new buckets down to the nearest 30 minutes. If a document with a time of 2023-03-27T18:24:35Z does not fit an existing bucket, MongoDB creates a new bucket with a minimum time of 2023-03-27T18:00:00Z and a maximum time of 2023-03-27T18:30:00Z.

Starting in MongoDB 5.3, you can create a collection with a clustered index. Clustered indexes are stored in the same WiredTiger file as the collection. The resulting collection is called a clustered collection.

The clusteredIndex field has the following syntax:

clusteredIndex: {
   key: <object>,
   unique: <boolean>,
   name: <string>
}

key

Required. The clustered index key field. Must be set to { _id: 1 }. The default value for the _id field is an automatically generated unique object identifier, but you can set your own clustered index key values.

unique

Required. Must be set to true. A unique index indicates the collection will not accept inserted or updated documents where the clustered index key value matches an existing value in the index.

name

Optional. A name that uniquely identifies the clustered index.

Optional.

Starting in MongoDB 6.0, you can use change stream events to output the version of a document before and after changes (the document pre- and post-images):

• The pre-image is the document before it was replaced, updated, or deleted. There is no pre-image for an inserted document.

• The post-image is the document after it was inserted, replaced, or updated. There is no post-image for a deleted document.

• Enable changeStreamPreAndPostImages for a collection using db.createCollection(), create, or collMod.

changeStreamPreAndPostImages has the following syntax:

changeStreamPreAndPostImages: {
   enabled: <boolean>
}

To enable change stream pre- and post-images for the collection, set enabled to true.

For complete examples with the change stream output, see Change Streams with Document Pre- and Post-Images.

For a create example on this page, see Create a Collection with Change Stream Pre- and Post-Images for Documents.

Optional. Available for the WiredTiger storage engine only.

Allows users to specify configuration to the storage engine on a per-collection basis when creating a collection. The value of the storageEngine option should take the following form:

{ <storage-engine-name>: <options> }

Storage engine configuration specified when creating collections are validated and logged to the oplog during replication to support replica sets with members that use different storage engines.

Starting in MongoDB 7.2, you can't specify wiredTiger storage engine encryption options when you create a collection with db.createCollection(). To configure encryption for the WiredTiger storage engine, see Encryption at Rest.

For more information, see Specify Storage Engine Options.

Optional. Allows users to specify validation rules or expressions for the collection.

The validator option takes a document that specifies the validation rules or expressions. You can specify the expressions using the same operators as the query operators with the exception of $near, $nearSphere, $text, and $where.

• Validation occurs during updates and inserts. Existing documents do not undergo validation checks until modification.

• You cannot specify a validator for collections in the admin, local, and config databases.

• You cannot specify a validator for system.* collections.

Optional. Determines how strictly MongoDB applies the validation rules to existing documents during an update.

"off"

No validation for inserts or updates.

"strict"

Default Apply validation rules to all inserts and all updates.

"moderate"

Apply validation rules to inserts and to updates on existing valid documents. Do not apply rules to updates on existing invalid documents.

Optional. Determines whether to error on invalid documents or just warn about the violations but allow invalid documents to be inserted.

Validation of documents only applies to those documents as determined by the validationLevel.

"error"

Default Documents must pass validation before the write occurs. Otherwise, the write operation fails.

"warn"

Documents do not have to pass validation. If the document fails validation, the write operation logs the validation failure.

Optional. Allows users to specify a default configuration for indexes when creating a collection.

The indexOptionDefaults option accepts a storageEngine document, which should take the following form:

{ <storage-engine-name>: <options> }

Storage engine configuration specified when creating indexes are validated and logged to the oplog during replication to support replica sets with members that use different storage engines.

The name of the source collection or view from which to create the view. The name is not the full namespace of the collection or view; i.e. does not include the database name and implies the same database as the view to create. You must create views in the same database as the source collection.

See also db.createView().

An array that consists of the aggregation pipeline stage(s). create creates the view by applying the specified pipeline to the viewOn collection or view.

A view definition pipeline cannot include the $out or the $merge stage. This restriction also applies to embedded pipelines, such as pipelines used in $lookup or $facet stages.

The view definition is public; i.e. db.getCollectionInfos() and explain operations on the view will include the pipeline that defines the view. As such, avoid referring directly to sensitive fields and values in view definitions.

See also db.createView().

Specifies the default collation for the collection or the view.

Collation allows users to specify language-specific rules for string comparison, such as rules for lettercase and accent marks.

The collation option has the following syntax:

collation: {
   locale: <string>,
   caseLevel: <boolean>,
   caseFirst: <string>,
   strength: <int>,
   numericOrdering: <boolean>,
   alternate: <string>,
   maxVariable: <string>,
   backwards: <boolean>
}

When specifying collation, the locale field is mandatory; all other collation fields are optional. For descriptions of the fields, see Collation Document.

If you specify a collation at the collection level:

• Indexes on that collection will be created with that collation unless the index creation operation explicitly specify a different collation.

• Operations on that collection use the collection's default collation unless they explicitly specify a different collation.

  You cannot specify multiple collations for an operation. For example, you cannot specify different collations per field, or if performing a find with a sort, you cannot use one collation for the find and another for the sort.

If no collation is specified for the collection or for the operations, MongoDB uses the simple binary comparison used in prior versions for string comparisons.

For a view, if no collation is specified, the view's default collation is the "simple" binary comparison collator. For a view on a collection, the view does not inherit the collection's collation settings. For a view on another view, the to be created view must specify the same collation settings.

After you create the collection or the view, you cannot update its default collation.

For an example that specifies the default collation during the creation of a collection, see Specify Collation.

Optional. A document that expresses the write concern for the operation. Omit to use the default write concern.

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

Optional. A document that configures Queryable Encryption for the collection being created.

To use encrypted fields in a collection, specify a new configuration option. You must have permissions to create and modify a collection to create or edit this configuration.

The configuration includes a list of fields and their corresponding key identifiers, types, and supported queries.

encryptedFieldsConfig = {
    "fields": [
      {
        "keyId": UUID,                    // required
        "path": String,                   // path to field, required
        "bsonType": "string" | "int" ..., // required
        "queries":                        // optional
        [
          { "queryType": "equality" },
        ]
      }
    ],
    "queryPatterns": [                    // optional
       {"fieldName": queryType, "fieldName": queryType, … }
    ]
}

For details, see Tutorials.

Optional. A user-provided comment to attach to this command. Once set, this comment appears alongside records of this command in the following locations:

• mongod log messages, in the attr.command.cursor.comment field.

• Database profiler output, in the command.comment field.

• currentOp output, in the command.comment field.

A comment can be any valid BSON type (string, integer, object, array, etc).