Ask why a cluster is slow, unstable, or expensive, and the answer is very often the same: shards. Sharding is the first architectural decision every index forces on you, it is awkward to change later, and both directions of getting it wrong have real costs. Here are the rules we actually apply, and how to see where your cluster stands.
Why shard strategy dominates
Every shard is a Lucene index: open files, segment metadata, and a slice of heap, forever, whether the shard is busy or idle. Every shard is also an entry in the cluster state that the master must track and publish. Too many shards and you burn heap and slow the master; too few and individual shards grow so large that recovery, rebalancing, and merges take hours. The goal is a corridor, not a single number.
The working rules
Target 10-50 GB per shard for logs and time-series data. Toward the upper end for append-only data with long retention; smaller when recovery speed matters more than shard count. Above ~50 GB, shard relocation and recovery times start dominating your incident timelines.
Keep search-facing shards smaller. For product and site search, latency matters more than density: 10-30 GB shards with more replicas usually behave better than 50 GB monoliths, because query fan-out is bounded by the slowest shard.
Respect the ~200M documents guideline per shard. Doc count stresses different structures than byte size; whichever ceiling you hit first is the one that counts.
Watch shards-per-node against heap. The old rule of thumb — at most ~20-25 shards per GB of heap — is conservative on recent versions, which handle cluster state far more efficiently, but it still catches pathological cases. A 30 GB-heap data node carrying 1,500 shards has a problem regardless of version.
Primary count is an ingest decision. Primaries parallelize indexing. One primary per index is fine at modest ingest rates; heavy streams need enough primaries to spread writes across data nodes — but each extra primary multiplies shard count across the retention window, so don't default to high counts.
Rollover, not daily indices
Daily indices are how clusters end up with thousands of tiny shards: a stream doing 2 GB a day with one primary and one replica creates 730 shards a year, mostly far below the corridor. Rollover inverts the logic — cut a new index when the shard reaches target size or a maximum age, whichever comes first. With ILM (or ISM on OpenSearch), set max_primary_shard_size to something like 40-50 GB and a max_age backstop of 30 days, and shard size stays in the corridor no matter how the stream's volume drifts.
Data streams make this the default pattern for time-series data on both Elasticsearch and OpenSearch; if you are still creating logs-2026.08.27-style indices by template, rollover is the single highest-value change on this page.
Fixing what already exists
For the backlog of small indices, two tools compose:
- Shrink an oversharded index to fewer primaries (the shrink API requires a factor of the original count — 6 to 3, 8 to 1).
- Force merge read-only indices down to one segment per shard after they stop receiving writes. Segments carry per-segment overhead; a rolled-over index merged to a single segment is smaller and faster to search. Never force-merge an index still being written.
Both belong in the warm phase of your lifecycle policy so they happen automatically, not as heroics.
How to see where you stand
Three API calls tell you most of the story:
GET _cat/shards?v&h=index,shard,prirep,docs,store,node&s=store:desc
GET _cat/nodes?v&h=name,heap.percent,node.role,shards
GET _cluster/health?filter_path=status,active_shards
Sort shards by store size and look at the distribution: a healthy log cluster shows most shards inside the corridor, a handful of active writers below it, and nothing enormous. Hundreds of megabyte-scale shards mean oversharding; shards north of 100 GB mean your next node failure will be a long afternoon.
The short version
Size shards 10-50 GB (smaller for search), let rollover enforce it, keep primaries proportional to ingest, and clean up the tail with shrink and force merge in the warm phase. None of this requires new hardware — which is exactly why it is usually the first finding in a cost review.