What Is an Index in Elasticsearch?
An Elasticsearch index is a logical collection of documents that share a similar structure, roughly analogous to a database in the relational world but backed by inverted indices for fast full-text search. Internally, every index is split into one or more shards, each of which is a self-contained Lucene instance capable of storing and searching documents independently, which is what lets Elasticsearch scale horizontally across nodes.
Cricket analogy: Just as a tournament like the IPL splits fixtures across multiple venues so no single stadium bears the whole load, an index splits documents across shards so no single Lucene instance carries the entire dataset.
Creating an Index with the REST API
You create an index explicitly with a PUT request to the index name, optionally supplying settings and mappings in the request body in a single atomic call; this is the recommended approach in production because it lets you control shard counts, analyzers, and field types before any document ever arrives, rather than relying on Elasticsearch to infer them from the first indexed document.
Cricket analogy: A captain naming the playing XI and setting the batting order before the toss, rather than deciding positions ball by ball, mirrors defining an index's settings and mappings up front via PUT rather than letting them be improvised.
curl -X PUT "localhost:9200/products" -H "Content-Type: application/json" -d '
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1
},
"mappings": {
"properties": {
"name": { "type": "text" },
"sku": { "type": "keyword" },
"price": { "type": "float" },
"created_at": { "type": "date" }
}
}
}'
Index Settings: Shards and Replicas
The number_of_shards setting is fixed at index creation time and cannot be changed afterward without reindexing into a new index, so it should be chosen based on expected data volume, typically a few tens of gigabytes per shard as a rough guideline. The number_of_replicas setting, by contrast, is dynamic and can be changed at any time; replicas are full copies of primary shards that provide both fault tolerance and additional read throughput.
Cricket analogy: A stadium's seating capacity is fixed once built, you cannot add stands mid-match, just as shard count is fixed at index creation, while ticket resale allocations can flex match to match, like replicas can be adjusted anytime.
As a rule of thumb, keep individual shards under roughly 50GB and avoid over-sharding small indices, an index with far more shards than nodes wastes resources on coordination overhead and can slow searches rather than speed them up.
Naming Conventions and Aliases
Index names must be lowercase and cannot contain characters like spaces, commas, or backslashes, and in production it is best practice to never write directly to a bare index name but instead point an alias at it, for example products pointing to products-000001, so that reindexing or rolling over to a new index can happen behind the scenes without changing application code.
Cricket analogy: A team playing under a fixed sponsor jersey name that can be swapped season to season without changing the squad underneath is like an alias pointing to whichever underlying index is currently live.
Never hardcode a bare, non-aliased index name into application queries in production. Without an alias, a reindex or rollover requires a coordinated code deploy; with an alias, you can repoint it atomically using the _aliases API with zero application downtime.
- An index is a logical collection of documents split internally into one or more shards.
- Use PUT with a JSON body to explicitly define settings and mappings before any documents are indexed.
- number_of_shards is fixed at creation time; number_of_replicas can be changed dynamically at any time.
- Keep shard sizes roughly under 50GB and avoid creating far more shards than your cluster has nodes.
- Index names must be lowercase and cannot contain spaces, commas, or backslashes.
- Point an alias at your index rather than writing to a bare index name, so rollovers stay transparent to applications.
- Replicas provide both fault tolerance and additional read throughput across the cluster.
Practice what you learned
1. Which index setting can be changed after the index has already been created?
2. What is the primary reason to point an alias at an index instead of writing directly to it?
3. Which of the following is a valid Elasticsearch index name?
4. Each shard in an Elasticsearch index is backed by what underlying technology?
5. What is a widely used rough guideline for maximum shard size?
Was this page helpful?
You May Also Like
Mapping Types Explained
Understand the core Elasticsearch field data types, text vs keyword, numbers, dates, and objects, and how each shapes search behavior.
Dynamic vs Explicit Mapping
Compare Elasticsearch's automatic field-type inference against explicitly defined mappings, and know when to use each.
Bulk Indexing
Learn how the _bulk API batches index, update, and delete operations into a single request for high-throughput ingestion.