---
title: "ClickHouse vs Prometheus for High Cardinality, Part 1: Understanding the Problem"
description: "Observability systems frequently encounter high cardinality when metrics contain numerous unique label combinations across multidimensional cloud infrastructure. In Prometheus, every unique label combination instantiates an independent time series that incurs metadata overhead, requires in-memory memSeries registration, and continually expands inverted index posting lists. The ingestion engine stores samples in two-hour Head blocks using compressed 120-sample chunks with XOR-based encodings, but rapid series creation and elevated scrape frequencies multiply chunk allocations and memory consumption. When executing read operations, broad aggregations and regular expressions require intersecting expansive posting lists and decoding entire chunks sequentially because the engine cannot push value predicates directly into compressed storage blocks. Consequently, managing high-cardinality workloads in series-oriented architectures forces operational trade-offs between system stability and granular visibility into ephemeral components."
---

# ClickHouse vs Prometheus for High Cardinality, Part 1: Understanding the Problem

[Clickhouse](https://yomu.fyi/company/clickhouse) · Rory Crispin, Dale McDiarmid · May 14, 2026

**Type:** Explainer

## Summary

Observability systems frequently encounter high cardinality when metrics contain numerous unique label combinations across multidimensional cloud infrastructure. In Prometheus, every unique label combination instantiates an independent time series that incurs metadata overhead, requires in-memory memSeries registration, and continually expands inverted index posting lists. The ingestion engine stores samples in two-hour Head blocks using compressed 120-sample chunks with XOR-based encodings, but rapid series creation and elevated scrape frequencies multiply chunk allocations and memory consumption. When executing read operations, broad aggregations and regular expressions require intersecting expansive posting lists and decoding entire chunks sequentially because the engine cannot push value predicates directly into compressed storage blocks. Consequently, managing high-cardinality workloads in series-oriented architectures forces operational trade-offs between system stability and granular visibility into ephemeral components.

## Context

Traditional time-series systems face severe memory overhead, ingestion latency, and query degradation when tracking high-cardinality metrics generated by ephemeral workloads and multidimensional infrastructure.

## Approach / What changed

The article analyzes Prometheus as a reference series-oriented model, detailing the underlying mechanics of memSeries allocations, chunk-based sample storage, inverted index posting lists, and read-path chunk decoding.

## Takeaways

- Each unique label combination in Prometheus creates an independent memSeries structure with approximately 200 bytes of base metadata plus chunk and label overhead.
- Inverted indexes store posting lists referencing all series for each label pair, expanding significantly in memory and write overhead as cardinality increases.
- Prometheus cannot push arbitrary value predicates down into compressed chunk storage, requiring full chunk decoding for every selected series during read operations.

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

- Source: [Clickhouse](https://clickhouse.com/blog/clickhouse-vs-promethous-high-cardinality-p1-understanding-the-problem)
- Source URL: https://clickhouse.com/blog/clickhouse-vs-promethous-high-cardinality-p1-understanding-the-problem
- Ingested by Yomu: 2026-08-28T01:25:55.203Z

[Read original post](https://clickhouse.com/blog/clickhouse-vs-promethous-high-cardinality-p1-understanding-the-problem)