create
On this page
Definition
create
Explicitly creates a collection or view.
Note
The view created by this command does not refer to materialized views. For discussion of on-demand materialized views, see
$merge
instead.
Syntax
The create
command has the following syntax:
Note
Starting in MongoDB 4.2
MongoDB removes the MMAPv1 storage engine and the MMAPv1 specific
option flags
for create
.
db.runCommand( { create: <collection or view name>, capped: <true|false>, timeseries: { timeField: <string>, metaField: <string>, granularity: <string> }, expireAfterSeconds: <number>, clusteredIndex: <document>, // Added in MongoDB 5.3 changeStreamPreAndPostImages: <document>, // Added in MongoDB 6.0 autoIndexId: <true|false>, size: <max_size>, max: <max_documents>, storageEngine: <document>, validator: <document>, validationLevel: <string>, validationAction: <string>, indexOptionDefaults: <document>, viewOn: <source>, pipeline: <pipeline>, collation: <document>, writeConcern: <document>, encryptedFields: <document>, comment: <any> }
Command Fields
The create
command has the following fields:
Field | Type | Description | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
create | string | The name of the new collection or view. See
Naming Restrictions. | ||||||||||||||||
capped | boolean | Optional. To create a capped collection,
specify true . If you specify true , you must also set a maximum
size in the size field. | ||||||||||||||||
timeseries.timeField | string | Required when creating a time series collection. The
name of the field which contains the date in each time series
document. Documents in a time series collection must have a
valid BSON date as the value for the timeField . | ||||||||||||||||
timeseries.metaField | string | 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 | ||||||||||||||||
timeseries.granularity | string | Optional. Possible values are "seconds" (default),
"minutes" , and "hours" . Set the granularity to the value
that is the closest match to the time span between consecutive
incoming measurements. Setting the granularity parameter
accurately improves performance by optimizing how data in the time
series collection is stored internally. | ||||||||||||||||
expireAfterSeconds | number | Optional. Specifies the seconds after which documents in a
time series collection or clustered collection
expire. MongoDB deletes expired documents automatically. | ||||||||||||||||
document | Starting in MongoDB 5.3, you can create a collection with a clustered index. Collections created with a clustered index are called clustered collections.
New in version 5.3. | |||||||||||||||||
document | 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):
For complete examples with the change stream output, see Change Streams with Document Pre- and Post-Images. For a New in version 6.0. | |||||||||||||||||
autoIndexId | boolean | Optional. Specify ImportantStarting in MongoDB 4.0, you cannot set the option Deprecated since version 3.2. | ||||||||||||||||
size | integer | Optional. Specify a maximum size in bytes for a capped collection. Once a
capped collection reaches its maximum size, MongoDB removes the older
documents to make space for the new documents. The size field is
required for capped collections and ignored for other collections. | ||||||||||||||||
max | integer | Optional. The maximum number of documents allowed in the capped collection. The
size limit takes precedence over this limit. If a capped
collection reaches the size limit before it reaches the maximum
number of documents, MongoDB removes old documents. If you prefer to
use the max limit, ensure that the size limit, which is
required for a capped collection, is sufficient to contain the
maximum number of documents. | ||||||||||||||||
storageEngine | document | 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
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. | ||||||||||||||||
validator | document | Optional. Allows users to specify validation rules or expressions for the collection. For more information, see Schema Validation. The Note
| ||||||||||||||||
validationLevel | string | Optional. Determines how strictly MongoDB applies the validation rules to existing documents during an update.
| ||||||||||||||||
validationAction | string | Optional. Determines whether to ImportantValidation of documents only applies to those documents as
determined by the
| ||||||||||||||||
indexOptionDefaults | document | Optional. Allows users to specify a default configuration for indexes when creating a collection. The
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. | ||||||||||||||||
viewOn | string | 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 | ||||||||||||||||
pipeline | array | An array that consists of the aggregation pipeline stage(s). A view definition The view definition is public; i.e. See also | ||||||||||||||||
collation | 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:
When specifying collation, the If you specify a collation at the collection level:
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. | |||||||||||||||||
writeConcern | document | Optional. A document that expresses the write concern for the operation. Omit to use the default write concern. When issued on a sharded cluster, | ||||||||||||||||
encryptedFields | document | 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.
For details, see Quick Start. | ||||||||||||||||
comment | any | Optional. A user-provided comment to attach to this command. Once set, this comment appears alongside records of this command in the following locations:
A comment can be any valid BSON type (string, integer, object, array, etc). New in version 4.4. |
The db.createCollection()
method and the
db.createView()
method wrap the create
command.
Behavior
Resource Locking
Changed in version 4.2.
create
obtains an exclusive lock on the
specified collection or view for the duration of the operation. All
subsequent operations on the collection must wait until
create
releases the lock. create
typically holds
this lock for a short time.
Creating a view requires obtaining an additional exclusive lock
on the system.views
collection in the database. This lock blocks
creation or modification of views in the database until the command
completes.
Transactions
Changed in version 4.4.
Starting in MongoDB 4.4, you can create collections and indexes inside a multi-document transaction if the transaction is not a cross-shard write transaction.
To use create
in a transaction, the transaction must use read
concern "local"
. If you specify a read concern level
other than "local"
, the transaction fails.
Stable API
Changed in version 5.0.
When using Stable API V1, you cannot specify
the following fields in a create
command:
autoIndexId
capped
indexOptionDefaults
max
size
storageEngine
Access Control
If the deployment enforces
authentication/authorization,
create
requires the following privileges:
Task | Required Privileges |
---|---|
Create a non-capped collection |
|
Create a capped collection |
|
Create a view |
However, if the user has the |
A user with the readWrite
built in role on the database
has the required privileges to run the listed operations. Either
create a user with the required role
or grant the role to an existing user.
Examples
Create a Capped Collection
To create a capped collection limited to 64 kilobytes, issue the command in the following form:
db.runCommand( { create: "collection", capped: true, size: 64 * 1024 } )
Create a Time Series Collection
To create a time series collection that captures weather data for the past 24 hours, issue this command:
db.createCollection( "weather24h", { timeseries: { timeField: "timestamp", metaField: "data", granularity: "hours" }, expireAfterSeconds: 86400 } )
Note
In this example expireAfterSeconds
is specified as 86400
which means documents expire 86400
seconds after the
timestamp
value. See Set up Automatic Removal for Time Series Collections (TTL).
Create a Clustered Collection
The following create
example adds a clustered
collection named products
:
db.runCommand( { create: "products", clusteredIndex: { "key": { _id: 1 }, "unique": true, "name": "products clustered key" } } )
In the example, clusteredIndex specifies:
"key": { _id: 1 }
, which sets the clustered index key to the_id
field."unique": true
, which indicates the clustered index key value must be unique."name": "products clustered key"
, which sets the clustered index name.
Create a Collection with Change Stream Pre- and Post-Images for Documents
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 usingdb.createCollection()
,create
, orcollMod
.
The following example creates a collection that has changeStreamPreAndPostImages enabled:
db.runCommand( { create: "temperatureSensor", changeStreamPreAndPostImages: { enabled: true } } )
Pre- and post-images are not available for a change stream event if the images were:
Not enabled on the collection at the time of a document update or delete operation.
Removed after the pre- and post-image retention time set in
expireAfterSeconds
.The following example sets
expireAfterSeconds
to100
seconds:use admin db.runCommand( { setClusterParameter: { changeStreamOptions: { preAndPostImages: { expireAfterSeconds: 100 } } } } ) The following example returns the current
changeStreamOptions
settings, includingexpireAfterSeconds
:db.adminCommand( { getClusterParameter: "changeStreamOptions" } ) Setting
expireAfterSeconds
tooff
uses the default retention policy: pre- and post-images are retained until the corresponding change stream events are removed from the oplog.If a change stream event is removed from the oplog, then the corresponding pre- and post-images are also deleted regardless of the
expireAfterSeconds
pre- and post-image retention time.
Additional considerations:
Enabling pre- and post-images consumes storage space and adds processing time. Only enable pre- and post-images if you need them.
Limit the change stream event size to less than 16 megabytes. To limit the event size, you can:
Limit the document size to 8 megabytes. You can request pre- and post-images simultaneously in the change stream output if other change stream event fields like
updateDescription
are not large.Request only post-images in the change stream output for documents up to 16 megabytes if other change stream event fields like
updateDescription
are not large.Request only pre-images in the change stream output for documents up to 16 megabytes if:
document updates affect only a small fraction of the document structure or content, and
do not cause a
replace
change event. Areplace
event always includes the post-image.
To request a pre-image, you set
fullDocumentBeforeChange
torequired
orwhenAvailable
indb.collection.watch()
. To request a post-image, you setfullDocument
using the same method.Pre-images are written to the
config.system.preimages
collection.The
config.system.preimages
collection may become large. To limit the collection size, you can setexpireAfterSeconds
time for the pre-images as shown earlier.Pre-images are removed asynchronously by a background process.
Important
Backward-Incompatible Feature
Starting in MongoDB 6.0, if you are using document pre- and post-images
for change streams, you must disable
changeStreamPreAndPostImages for each collection using
the collMod
command before you can downgrade to an earlier
MongoDB version.
Tip
See also:
For change stream events and output, see Change Events.
To watch a collection for changes, see
db.collection.watch()
.For complete examples with the change stream output, see Change Streams with Document Pre- and Post-Images.
Create a View
Note
The view created by this command does not refer to materialized
views. For discussion of on-demand materialized views, see
$merge
instead.
Changed in version 4.2.
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.
To create a view using the create
command, use the following syntax:
db.runCommand( { create: <view>, viewOn: <source>, pipeline: <pipeline> } )
or if specifying a collation:
db.runCommand( { create: <view>, viewOn: <source>, pipeline: <pipeline>, collation: <collation> } )
For example, create a survey
collection with the following documents:
db.survey.insertMany( [ { _id: 1, empNumber: "abc123", feedback: { management: 3, environment: 3 }, department: "A" }, { _id: 2, empNumber: "xyz987", feedback: { management: 2, environment: 3 }, department: "B" }, { _id: 3, empNumber: "ijk555", feedback: { management: 3, environment: 4 }, department: "A" } ] )
The following operation creates a managementRatings
view with the
_id
, feedback.management
, and department
fields:
db.runCommand ( { create: "managementFeedback", viewOn: "survey", pipeline: [ { $project: { "management": "$feedback.management", department: 1 } } ] } )
Important
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.
Specify Collation
You can specify collation at the collection or view level. For example, the following operation creates a collection, specifying a collation for the collection (See Collation Document for descriptions of the collation fields):
db.runCommand ( { create: "myColl", collation: { locale: "fr" } });
This collation will be used by indexes and operations that support
collation unless they explicitly specify a different collation. For
example, insert the following documents into myColl
:
{ _id: 1, category: "café" } { _id: 2, category: "cafe" } { _id: 3, category: "cafE" }
The following operation uses the collection's collation:
db.myColl.find().sort( { category: 1 } )
The operation returns documents in the following order:
{ "_id" : 2, "category" : "cafe" } { "_id" : 3, "category" : "cafE" } { "_id" : 1, "category" : "café" }
The same operation on a collection that uses simple binary collation (i.e. no specific collation set) returns documents in the following order:
{ "_id" : 3, "category" : "cafE" } { "_id" : 2, "category" : "cafe" } { "_id" : 1, "category" : "café" }
Specify Storage Engine Options
You can specify collection-specific storage engine configuration
options when you create a collection with
db.createCollection()
. Consider the following operation:
db.runCommand( { create: "users", storageEngine: { wiredTiger: { configString: "<option>=<setting>" } } } )
This operation creates a new collection named users
with a
specific configuration string that MongoDB will pass to the
wiredTiger
storage engine. See the WiredTiger documentation of
collection level options
for specific wiredTiger
options.