The Bulk API at Scale and Reindexing

Build the mental model

You cannot change a mapping (like a field type) directly on an index that already exists — the inverted index is built ahead of time according to field type, so changing a type requires reindexing every document into a brand-new index. Elasticsearch's `_reindex` API copies every document from a source index into a destination index (carrying the new mapping), and to do this without downtime you use the "alias" pointer concept — application code queries an alias name (`tutorials`) instead of referencing the real index name (`tutorials_v1`) directly, so once reindexing finishes, atomically swapping the alias to the new index (`tutorials_v2`) achieves zero-downtime migration without touching application code at all. Reindexing operations use the `_bulk` API internally on large datasets, so everything from Lesson 5 about bulk mechanics (chunking, per-item error checking) still applies here — with a very large document count, the reindex operation can also run as a background task whose progress you poll. Think of it like renovating a house: you stay in the old house (no downtime) while building the new one next door, then swap the address sign (the alias) over once it's ready.

Connect it to a real scenario

Suppose the Tutorial Platform team wants to change the `body` field's analyzer (from `standard` to `english`) — like a mapping change, this also needs existing documents reindexed. First create `tutorials_v2` with the new analyzer's mapping, run the `_reindex` API from `tutorials_v1` to `tutorials_v2`, verify the two document counts match (with the `_count` API), and only then atomically swap the `tutorials` alias from `tutorials_v1` to `tutorials_v2` (a single `_aliases` API call combining remove and add) — so `GET /tutorials/_search` requests in application code never notice any interruption.

Changing mapping or analyzer requires reindexing into a new index
An alias is an index-name indirection layer, used for a zero-downtime swap
Reindex operations are internally bulk-based and their progress can be polled

Try the working example

http

PUT /tutorials_v2
{
  "mappings": {
    "properties": {
      "body": { "type": "text", "analyzer": "english" }
    }
  }
}

POST /_reindex
{
  "source": { "index": "tutorials_v1" },
  "dest": { "index": "tutorials_v2" }
}

POST /_aliases
{
  "actions": [
    { "remove": { "index": "tutorials_v1", "alias": "tutorials" } },
    { "add": { "index": "tutorials_v2", "alias": "tutorials" } }
  ]
}

You should see

All documents are copied into `tutorials_v2` with the new analyzer, and the `tutorials` alias swaps to the new index with zero downtime.

5-minute try-it

Suppose you want to change `lessonCount` from `integer` to `long` — write the four-step request sequence: create `tutorials_v3`, reindex, verify document count, and swap the alias.

One important caution

Assuming an existing index's mapping field type can be changed directly with `PUT /_mapping` — reindexing is the only real way to change a field type.

Hardcoding the real index name in application code (referencing `tutorials_v1` directly) instead of swapping an alias — this forces a redeploy of application code on every reindex or migration, an unnecessary coupling.

Elasticsearch Guide — Reindex API — Elastic