In-place columns for hot counters and flags #

Fields that change constantly — view counters, stock levels, feature flags, ranking scores — used to pay a full document rebuild on every partial update. Marking a numeric or boolean field with "inplace": true gives it a dedicated typed column instead:

PUT /my-collection
{
  "properties": {
    "title": { "type": "keyword" },
    "views": { "type": "integer", "inplace": true },
    "score":  { "type": "double",  "inplace": true },
    "active": { "type": "boolean", "inplace": true }
  }
}

Partial updates on such fields become O(1) column writes — no fetch, merge, and re-index of the document. Atomic-style operators work directly against the column:

POST /my-collection/_update/0,1
{
  "ops": [
    { "op": "incr",   "field": "views",  "value": 1 },
    { "op": "toggle", "field": "active" },
    { "op": "max",    "field": "score",  "value": 9.9 }
  ]
}

Term, terms, and range queries on these fields are answered by the column itself, with block-level summaries that skip whole 4 096-slot blocks that cannot contain the queried range — narrow range filters stay cheap even as the corpus and the update rate grow.

Semantics worth knowing before you opt a field in:

• Visibility. A column write is visible the moment it lands. A search snapshot pins the set of documents but reads the latest values, so a long-running aggregation over a hot counter observes mid-flight values (the deviation is bounded by the update rate times the query duration — usually negligible, and exactly what a metrics field wants). Fields that need strict snapshot isolation should stay regular.
• Arithmetic. A missing numeric field starts from 0, a missing boolean from false. Integer incr/mul wrap on overflow instead of erroring. Repeated float additions accumulate rounding drift — prefer an integer counter and format for display.
• Mixed updates. A request that mixes inplace fields with regular fields (or repeats a field, or carries a doc body) takes the regular read-modify-write path; results are the same, the document keeps its _id, and every write is covered by the WAL.
• Query pruning. The block summaries prune by value locality: fields whose values correlate with write order (timestamps, counters, epochs) prune best. A uniformly random field over a wide range prunes little — such fields are better served by a regular indexed field.

See Field parameters and Partial update a document for the full contract.