ML
Elasticsearch

Shard Sizing: The Single Most Important Elasticsearch Decision

Too few shards and you can't scale out; too many and the cluster state eats your heap. The middle is narrower than you think.

August 18, 20258 min readElasticsearchOperations

A shard is a Lucene index. Every shard costs heap (for mappings, field data, segment metadata) and every shard is a unit of replication. Getting the count right is the single highest-impact decision in running Elasticsearch.

The numbers that matter

  • Target shard size: 10–50 GiB for search-heavy, up to 65 GiB for log ingest.
  • Shards per node: budget 20 shards per GiB of heap (so a 32 GiB heap node handles ~600 shards comfortably).
  • Heap per node: cap at 31 GiB — above that you lose compressed ordinary object pointers.

Too many shards

Cluster state is held in memory on every node. Ten thousand shards means tens of thousands of mapping entries replicated around the cluster — master nodes spend their time gossiping instead of working. Symptoms: slow index creation, long master election, memory pressure with tiny data volume.

Too few shards

You can't parallelise. Since shards are the unit of search, a 2 TiB index in 4 shards gives you 4-way fan-out max; even a 50-node cluster will only use 4 of those nodes for that query.

ILM and rollover — the modern answer

Stop pre-sizing a giant index. Use Index Lifecycle Management with a rollover at, say, 50 GiB or 30 days:

PUT _ilm/policy/logs
{
  "policy": {
    "phases": {
      "hot":    { "actions": { "rollover": { "max_size": "50gb", "max_age": "30d" } } },
      "warm":   { "min_age": "30d", "actions": { "forcemerge": { "max_num_segments": 1 } } },
      "cold":   { "min_age": "90d", "actions": { "freeze": {} } },
      "delete": { "min_age": "365d", "actions": { "delete": {} } }
    }
  }
}

You write to an alias, ES rotates underlying indices at the size/age you pick, old tiers migrate to cheaper nodes. Shard count emerges from the policy instead of being guessed up front.

Do you even need replicas?

In a log-analytics cluster with reliable source ingestion, replicas mostly exist for availability. Running the hot tier at number_of_replicas=1 and warm/cold at 0 is a common way to halve storage spend without changing durability guarantees.

SharePostLinkedIn

Reader Discussion

6 replies// weighed in

TopNewestAuthor
Add to the thread
Disagree, agree harder, or share your own experience…
Email instead →markdown okbe kind
  1. Highlighted by author
    Raghav Sharma· Search Engineer · FlipkartFrom experience

    rescore vs raw function_score is the single biggest relevance win I've shipped this year. +0.08 NDCG@10 on product search, zero recall regression, two weeks of work. If you have a serious search funnel and you're not rescoring, you're leaving money on the table.

    Aug 20, 2025·2 days later
  2. Pierre Lambert· Senior EngineerAgrees

    people obsess over the query and ignore the analyzer. half the relevance bugs I've debugged were because the index analyzer and the search analyzer disagreed. boring fix, huge wins.

    Aug 24, 2025·6 days later
  3. Rashida Hassan· ML EngAsks

    would love a follow-up on hybrid bm25 + dense vector search in 8.x. we A/B'd it last quarter and the BM25 head still wins on long-tail queries by a surprising margin.

    Aug 25, 2025·1 week later
  4. Olivia Bennett· Data EngineerStory

    Mapping explosion off untrusted JSON cost us a 2-billion-doc reindex last year. Six engineers, two weekends, one director apology email. "Never ingest untrusted JSON" should be on the office wall in 72pt.

    Aug 22, 2025·4 days later
  5. Michiel de Vries· Observability LeadAgrees

    ILM + rollover turned our cluster from a 4-times-a-week pager generator into something on-call literally forgets exists for months at a time. If a post wants one takeaway it should be this.

    Aug 21, 2025·3 days later
  6. Isabella Costa· Junior EngineerKind words

    saved this. sharing at standup tomorrow — we've had exactly this problem for 2 sprints and nobody on the team had framed it this way 🙏

    Aug 20, 2025·2 days later

Worked on something similar? Email ducminhldm@gmail.com — I read every one. The good ones become future posts.

Comments seeded · live discussion via email