A data type tells Elasticsearch how to represent, index, and search a document field. In a movie record, a title and synopsis are textual values, a release date is a date, and gross earnings can be a floating-point number. These choices become mapping rules: they describe the document shape and determine how each field is handled during indexing. section 4.0 section 4.1
Choosing the right type affects what a field can do. Text fields can use full-text rules, while structured values such as dates and numbers can participate in filtering, sorting, and aggregations. Elasticsearch stores different types in suitable retrieval structures, including inverted indexes for text and BKD trees for numeric fields, so accurate types support reliable search results. section 4.0 section 4.1.1
Elasticsearch groups its many data types into practical families:
- Simple types represent common values: text, keyword, boolean, dates, whole numbers, floating-point numbers, and binary data. section 4.4
- Complex types model composed JSON data: object, nested, flattened, and join. section 4.4
- Specialized types support focused use cases, including geo_point and geo_shape for locations, ip addresses, and range values. section 4.4 section 12.1
Table 4.1 Common data types with examples (view table figure)
Compare common field types with the business values they represent before designing a mapping. section 4.4
A mapping can be explicit or dynamic. With dynamic mapping, Elasticsearch derives a field type when it first sees a value: a movie title string becomes text, an ISO 8601 release-date string becomes date, and a numeric rating becomes float. This is useful for development and testing, but defining a schema first is preferable when the data model is known. section 4.2 section 4.8
Product fields chosen for search
An electrical-products index defines price and user_ratings as double values. Other attributes are text fields, and fields such as colour or energy_rating may use multiple types, including text and keyword, when both full-text and term-level queries are needed. Type selection follows the queries the application must support. section 11.1.1
Listing 11.1 Defining the products schema
PUT products
{
"mappings": {
"properties": {
"brand": {
"type": "text"
},
"colour": {
"type": "text"
},
"energy_rating": {
"type": "text"
},
...
"user_ratings": {
"type": "double"
},
"price": {
"type": "double"
}
}
}
}
Inspect a mapping that creates an empty products index and assigns types before documents are indexed. section 11.1.1
Type coercion can reduce indexing failures when an incoming value differs from the mapped type. For example, a field mapped as an integer can accept the string "2" if Elasticsearch can parse it as the expected numeric value. Coercion is not a substitute for clean input: it works only when the value matches the target type after parsing. section 4.3.4
