---
title: "Index sharding in ClickHouse Cloud: Petabyte-scale data needs petabyte-scale indexing"
description: "In large-scale ClickHouse Cloud deployments, replicas traditionally load entire primary and secondary indexes from object storage into working memory, creating massive redundant memory overhead as fleets expand. Index sharding resolves this bottleneck by distributing the index analysis phase across available replicas using consistent hashing over data parts. Instead of every node loading full index structures, each replica loads and analyzes only its assigned fraction of primary keys, bloom filters, text indexes, or vector indexes. The query initiator merges the resulting granule match ranges, allowing parallel replicas to stream data without any single machine retaining the whole index. This approach freed working memory for query execution and accelerated index analysis by up to 7.7x in benchmark tests on a 50 billion row table."
---

# Index sharding in ClickHouse Cloud: Petabyte-scale data needs petabyte-scale indexing

[Clickhouse](https://yomu.fyi/company/clickhouse) · James Cunningham · Apr 21, 2026

**Type:** Problem & solution

## Summary

In large-scale ClickHouse Cloud deployments, replicas traditionally load entire primary and secondary indexes from object storage into working memory, creating massive redundant memory overhead as fleets expand. Index sharding resolves this bottleneck by distributing the index analysis phase across available replicas using consistent hashing over data parts. Instead of every node loading full index structures, each replica loads and analyzes only its assigned fraction of primary keys, bloom filters, text indexes, or vector indexes. The query initiator merges the resulting granule match ranges, allowing parallel replicas to stream data without any single machine retaining the whole index. This approach freed working memory for query execution and accelerated index analysis by up to 7.7x in benchmark tests on a 50 billion row table.

## Context

At petabyte scale with hundreds of billions of rows, every replica had to redundantly load the entire primary key and secondary indexes into memory from object storage before determining which granules to read. This fixed memory cost scaled linearly with replica count, consuming hundreds of gigabytes per node that could otherwise serve query execution.

## Approach / What changed

ClickHouse Cloud introduced Index Sharding for SharedMergeTree tables, which partitions index evaluation across replicas using consistent hashing on a virtual hash ring. Each replica loads and analyzes only its assigned subset of data parts across primary, bloom filter, full-text, and vector indexes, after which the initiator aggregates the matching granule ranges for parallel data reading.

## Takeaways

- Index sharding distributes index analysis across replicas using consistent hashing, requiring each of N replicas to load only 1/N of the total index.
- In ClickHouse tests on a 50 billion row table, distributing index evaluation accelerated index analysis time by up to 7.7x.
- The partitioning mechanism covers primary key indexes as well as secondary indexes like bloom filters, full-text search, and vector search.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [Performance](https://yomu.fyi/topic/performance), [Scalability](https://yomu.fyi/topic/scalability)

- Source: [Clickhouse](https://clickhouse.com/blog/index-sharding-clickhouse-cloud-petabyte-scale-indexing)
- Source URL: https://clickhouse.com/blog/index-sharding-clickhouse-cloud-petabyte-scale-indexing
- Ingested by Yomu: 2026-08-28T01:24:42.849Z

[Read original post](https://clickhouse.com/blog/index-sharding-clickhouse-cloud-petabyte-scale-indexing)