---
title: "Sharding etcd on hosted control planes and what the numbers actually say"
description: "Sharding etcd on hosted control planes splits the key-value store into multiple instances by resource kind, a tech preview feature tested with a main shard for cluster state and a dedicated events shard on Red Hat OpenShift 4.21 with HyperShift. Under event pressure from synthetic storms and realistic crashlooping pods, the sharded configuration showed up to 96% fewer slow applies, faster compaction and raft snapshot durations, and 60% more WAL fsyncs and 90% more backend commits combined. The sharded arm never failed the event storm workload, while the standard arm occasionally did. Pod-ready latencies and workload finish times remained comparable across both configurations. The trade-offs are roughly 1.8 to 2.3 times the etcd container memory and a compaction regression under large custom resource quota pressure that is still under investigation."
---

# Sharding etcd on hosted control planes and what the numbers actually say

[Red Hat](https://yomu.fyi/company/red-hat) · Vishnu Challa · Oct 13, 2026

**Type:** Benchmark

## Summary

Sharding etcd on hosted control planes splits the key-value store into multiple instances by resource kind, a tech preview feature tested with a main shard for cluster state and a dedicated events shard on Red Hat OpenShift 4.21 with HyperShift. Under event pressure from synthetic storms and realistic crashlooping pods, the sharded configuration showed up to 96% fewer slow applies, faster compaction and raft snapshot durations, and 60% more WAL fsyncs and 90% more backend commits combined. The sharded arm never failed the event storm workload, while the standard arm occasionally did. Pod-ready latencies and workload finish times remained comparable across both configurations. The trade-offs are roughly 1.8 to 2.3 times the etcd container memory and a compaction regression under large custom resource quota pressure that is still under investigation.

## Context

The post evaluates etcd sharding, a tech preview feature for hosted control planes, by comparing a two-shard configuration (main and events) against a single etcd instance under four workload variants on Red Hat OpenShift 4.21 with HyperShift.

## Approach / What changed

Split etcd into two shards: a main shard holding cluster state and a dedicated events shard, routing resources by kind.

## Takeaways

- Sharding reduces slow applies by up to 96% under event pressure, with faster compaction and raft snapshots.
- Sharding increases total write throughput (60% more WAL fsyncs, 90% more backend commits) but costs 1.8–2.3x etcd container memory.
- The only regression is a compaction slowdown under large custom resource quota pressure, still under investigation.

## FAQ

### What is the memory cost of etcd sharding?

Roughly 1.8 to 2.3 times the etcd container memory, unexplained by DB-sizing metrics, possibly a per-container floor rather than a per-shard cost.

### Does sharding affect end-user pod latency?

No, pod-ready latencies and workload finish times were comparable across both configurations in all workload variants tested.

### What workload caused a regression in sharding?

The db-quota-pressure workload with large custom resources showed a compaction regression, with the sharded arm taking 2.5x longer to compact, still under investigation.

**Tags:** [etcd](https://yomu.fyi/topic/etcd), [Kubernetes](https://yomu.fyi/topic/kubernetes), [OpenShift](https://yomu.fyi/topic/openshift)

- Source: [Red Hat](https://developers.redhat.com/articles/2026/10/13/sharding-etcd-on-hosted-control-planes-and-what-the-numbers-actually-say)
- Source URL: https://developers.redhat.com/articles/2026/10/13/sharding-etcd-on-hosted-control-planes-and-what-the-numbers-actually-say
- Ingested by Yomu: 2026-10-13T15:00:15.607Z

[Read original post](https://developers.redhat.com/articles/2026/10/13/sharding-etcd-on-hosted-control-planes-and-what-the-numbers-actually-say)