_id field [mapping-id-field]

Each document has an _id that uniquely identifies it, which is indexed so that documents can be looked up either with the GET API or the ids query. The _id can either be assigned at indexing time, or a unique _id can be generated by {{es}}. The _id field has limited configurability in the mappings; see Parameters for _id fields.

The value of the _id field is accessible in queries such as term, terms, match, and query_string.

# Example documents
PUT my-index-000001/_doc/1
{
  "text": "Document with ID 1"
}

PUT my-index-000001/_doc/2?refresh=true
{
  "text": "Document with ID 2"
}

GET my-index-000001/_search
{
  "query": {
    "terms": {
      "_id": [ "1", "2" ] <1>
    }
  }
}

1. Querying on the _id field (also see the ids query)

The _id field is restricted from use in aggregations, sorting, and scripting. In case sorting or aggregating on the _id field is required, it is advised to duplicate the content of the _id field into another field that has doc_values enabled.

::::{note} _id is limited to 512 bytes in size and larger values will be rejected.

::::

Parameters for _id fields [mapping-id-field-params]

stack: preview 9.5
serverless: preview

The _id field accepts the following mapping parameter:

mode : Controls how the _id value is stored and retrieved. Accepted values are:

- `document` — The `_id` is stored as a stored field and indexed. This is the standard behaviour. This is default for document based index modes.
- `columnar` — The `_id` is stored as binary doc values and indexed, but not as a stored field. This reduces per-document overhead when the index uses a columnar storage layout (for example, the `logsdb_columnar` index mode) where doc values are already being read for most fields. This is the default for columnar based index modes.

```console
PUT my-columnar-index
{
  "mappings": {
    "_id": {
      "mode": "columnar"
    }
  }
}
```