createIndexes

Parameters

Index specification

DocumentDB-specific index options

These are accepted directly in an index specification or inside storageEngine:

Regular and composite indexes

Both examples use the default ordered/composite index format without explicitly selecting it.

Regular index: Create a single-field index for arrival-airport lookups:

db.flights.createIndex(
  { arrival_airport: 1 },
  { name: "arrival_airport_1" }
)

db.flights.find({ arrival_airport: "LED" })

Composite (ordered) index: Index the departure airport followed by scheduled departure time, for queries that filter by airport and sort by departure time:

db.flights.createIndex(
  { departure_airport: 1, scheduled_departure: 1 },
  { name: "departure_airport_1_scheduled_departure_1" }
)

db.flights.find({ departure_airport: "SVO" }).sort({ scheduled_departure: 1 })

An ordered/composite index can also have a single field. The key document specifies the indexed fields and their order.

Unique, blocking, and TTL indexes

Unique index: Enforce uniqueness of the combination of route number and scheduled departure. Existing documents must already satisfy the constraint.

db.flights.createIndex(
  { route_no: 1, scheduled_departure: 1 },
  { name: "route_no_1_scheduled_departure_1_unique", unique: true }
)

Blocking index: Request a blocking build for this index through storageEngine.blocking. A blocking build can block writes to the collection while it runs.

db.flights.createIndex(
  { departure_airport: 1 },
  {
    name: "departure_airport_1_blocking",
    storageEngine: { blocking: true }
  }
)

TTL index: An application can keep short-lived flight events in a separate flight_events collection. Store recorded_at as a BSON date and expire events 24 hours after that timestamp:

db.flight_events.insertOne({
  flight_id: 101,
  event: "check_in_opened",
  recorded_at: new Date()
})

db.flight_events.createIndex(
  { recorded_at: 1 },
  { name: "recorded_at_ttl", expireAfterSeconds: 86400 }
)

TTL indexes must be single-field indexes and cannot target _id. Deletion happens asynchronously through TTL cleanup, not exactly at the expiration timestamp.

Vector index options

Other vector implementations can register additional kinds and options; those are not part of the default built-in wire surface.

db.flights.createIndex(
  { route_vector: "cosmosSearch" },
  {
    name: "route_vector_index",
    cosmosSearchOptions: {
      kind: "vector-hnsw",
      similarity: "COS",
      dimensions: 3,
      m: 16,
      efConstruction: 64
    }
  }
)

Text index representations

Text indexes support two representations. The following examples describe the same text index over the flight's departure and arrival airport fields; choose one representation rather than creating two indexes.

Field-name representation: Set each indexed field to "text" in the key document. Fields have weight 1 unless overridden with weights.

db.flights.createIndex(
  { departure_airport: "text", arrival_airport: "text" },
  { name: "flight_airports_text" }
)

Metadata representation: Use { _fts: "text", _ftsx: 1 } as the key document and identify the actual indexed fields and their weights in weights. _fts and _ftsx are index metadata markers, not fields you need to add to your documents. This is also the key representation used in listIndexes output.

db.flights.createIndex(
  { _fts: "text", _ftsx: 1 },
  {
    name: "flight_airports_text",
    weights: { departure_airport: 1, arrival_airport: 1 }
  }
)

For a wildcard text index, use { "$**": "text" } in the field-name representation, or the metadata key document with weights: { "$**": 1 }.

Build a unique index on existing data

Use this staged workflow to add uniqueness to a collection that already contains documents. It requires prepare-unique and unique-conversion support to be enabled in the deployment. The example is an alternative to the direct unique: true example above; start without that index already created.

1. Build the index for uniqueness conversion

Create the index with storageEngine.buildAsUnique: true, without setting unique: true. Wait for index creation to complete before proceeding. An ordinary non-unique index created without buildAsUnique is not eligible for this workflow.

db.flights.createIndex(
  { route_no: 1, scheduled_departure: 1 },
  {
    name: "route_no_1_scheduled_departure_1_unique",
    storageEngine: { buildAsUnique: true }
  }
)

2. Prevent new duplicate keys

Use collMod to set prepareUnique: true. This starts rejecting writes that would introduce duplicate index keys; it does not resolve existing duplicates. Correct any existing duplicate combinations of route number and scheduled departure before the next step.

db.runCommand({
  collMod: "flights",
  index: {
    name: "route_no_1_scheduled_departure_1_unique",
    prepareUnique: true
  }
})

3. Validate existing data and convert

Set unique: true in a separate collMod request. This validates existing indexed data and, if validation succeeds, converts the index to a unique index. If duplicate keys remain, conversion fails; correct the conflicting data and retry this step.

db.runCommand({
  collMod: "flights",
  index: {
    name: "route_no_1_scheduled_departure_1_unique",
    unique: true
  }
})

Do not combine prepareUnique and unique in the same request. After successful conversion, the index is reported as unique and enforces uniqueness for the indexed key combination.

Appendix: Ordered-index option

Ordered/composite indexing is enabled by default, so normal index creation does not require enableOrderedIndex. When needed, the option is accepted directly in an index specification or inside storageEngine.

See wire protocol and common fields. Source: pg_documentdb/src/commands/create_indexes.c, ParseCreateIndexesArg, ParseIndexDefDoc, ParseCustomIndexDefOption, and pg_documentdb/src/vector/vector_index_kind_impl.c; uniqueness conversion: pg_documentdb/src/commands/coll_mod.c, HandleUniqueConversion and UpdatePostgresIndexesForUnique.